[smallerfish]

> 2. Postgre is not serverless, so it is not easy to separate read and write, and it is not easy to auto scaling

By the time you're hitting the limitations of vertical scaling a single do-everything instance of Postgres on cloud infrastructure, you're making boatloads of money and can afford to stand up something else for search. And besides which, creating read replicas horizontally is very doable.

Though to be fair, I wouldn't implement moderately complex search on postgres, just because there are better tools for the job. Keeping data consistent between multiple systems though is "involved", and there's therefore a good argument for doing search in Postgres if your needs are simple.

[hamandcheese]

You don't have to be that big for mixed workloads to cause issues for a do-everything PG instance.

Imagine a scenario where read-heavy but infrequent search queries end up pushing, say, your sessions table out of cache.

Postgres has no facilities for earmarking cache for one table vs another, so the noisy neighbor problem is real, and hard to fix. You can throw money/ram at it, but that's needlessly expensive if you have some workloads that don't require that level of performance.

[LunaSea]

You can get 512GB RAM and 96 core machines for $1000 / month and at that point you can throw any workload on it.

[ForHackernews]

Parent comment already mentioned read-replicas.

The main problem I've seen is companies allowing tables to grow enormous because they never partition (by year, for instance) or archive out old stale data.