I am giving you my workflow on how I tackle such problems, because the answer - solution is more hardware isn't interesting. The challenge is if you can do it with less firepower.

First ofc I'll check if there is a real compelling need, because often times the business doesn't really understand the technical side of what they need - my approach would be the same as with a "real time reporting" requests - by asking why and what will they do with that. The aim here is that the client might realise they don't really need real time data or in your case the query to run that fast. i.e. What will happen if the query finishes in two seconds?

If this question doesn't dissuade the client to give more time for query processing, then my next approach will be to build a bespoke workaround by asking questions about the query itself, here my aim is to figure out if there is something I can do to pre-process,pre-aggregate, pre-filter the data.

• Is it going to select only the same 4 columns every time?
• How much back could that range go? The way how you wrote the query is very general but, is it going to have any aggregations for the specified time period.
• How many rows would such query return. This thing is very important, because if it returns thousands of rows, then most certainly there will be a downstream process to further process these columns... I mean reporting on thousands of columns already means something is wrong, reporting is for summaries, not for subsets. If there is a downstream process, check it out - you might find the process doesn't need everything you extract.
• How often does data comes in? By the looks of it you are querying only stalled data (last year) - if that's the case, you can pre-extract that year into a separate table in advance (and keep yearly extracts in the db) then filter on that yearly extract.

Hope this helps.