Choosing a technology to solve a problem before the problem is well understood is the best way to lose time and energy.

First of all, the volumes that you indicate are not very high. There are a lot of RDBMS based solutions that handle much higher volumes. Moreover, it seems not either to be a very complex query: no join, only value selection. A selection on a combination of several fields is something that an RDBMS usually does at least as well as a NoSQL. The advantage of NoSQL lies elsewhere.

So the first thing to do is to be able to measure the performance under heavy load, and identify the root-cause:

• is it really the query on the table? Then, was the query analysed and optimised, e.g. what about adding some indexes, including composite indexes?
• or is it because the database is also under heavy load due to other activities? In this case, could it be considered to use a different isolation level, to reduce locking that may create unexpected bottlenecks?

In the worst case, before considering NoSQL, why not simply create or replicate this table in another instance, or another cluster? This seems relevant if your table is created periodically via a cronjob and is a read-only, and if it is not involved in transactional stuff. It would have the advantage of keeping the technology stack homogeneous, while distributing the workload.

I also read in other answer that NoSQL would be more scalable. Maybe, maybe not. NoSQL is not better, it's different. There are things that it can do better (store flexible data structures in document dbs, have lighter retrieval if the problem can be expressed in terms of key-values, navigate more efficiently across complex evolving structures, if the problem can be expressed as a graph, ...). Postgres and RDBMSes in general are also scalable, with sharding, partitioning, and replication. Again, this solves only some kind of problems and should not be seen as a general performance claim.

My whole point is not that Postgres can do everything and you should keep it, but that you should make your choice based on evidence and a good understanding of the root cause.

Choosing a technology to solve a problem before the problem is well understood is a good way for wasting time and energy.

First of all, the volumes that you indicate are not very high. I have seen a lot of RDBMS-based solutions that handle much higher volumes without any performance issue. Moreover, it seems not either to be a very complex query: no join, only value selections. A selection on a combination of several fields is something that an RDBMS usually does at least as well as a NoSQL. The advantage of NoSQL lies elsewhere.

The first step to the solution is to be able to measure the performance under heavy load, and identify the root-cause:

• is it really the query on the table? Then, was the query analysed and optimised, e.g. what about adding some indexes, including composite indexes?
• or is it because the database is also under heavy load due to other activities? In this case, could it be considered to use a different isolation level, to reduce locking that may create unexpected bottlenecks?

In the worst case, before considering NoSQL, why not simply create or replicate this table in another instance, or another cluster? This seems relevant if your table is created periodically via a cronjob, is read-only, and moreover not involved in transactional stuff. It would have the advantage of keeping the technology stack homogeneous, while distributing the workload.

I also read in other answer that NoSQL would be more scalable. Maybe, maybe not. NoSQL is not better, it's different. It's not a performance guarantee: There are things that NoSQL can do better (store flexible data structures in document dbs, have lighter retrieval if the problem can be expressed in terms of key-values, navigate more efficiently across complex evolving structures, if the problem can be expressed as a graph, ...).But each of this advantage come with some inconvenience as well. Postgres and RDBMSes in general are also scalable, with sharding, partitioning, and replication. Again, this is not a universal solution and solves only some kind of problems.

My whole point is not that Postgres can do everything and you should keep it, but that you should make your choice based on evidence and a good understanding of the root cause.