Hacker News Reader

Comment by WJW | Hacker News Reader

Posts with the basic messgage "Use nothing but postgres for everything from pubsub to background job queues, it's the best thing since sliced bread and will solve all your problems" have been a HN staple for at least a decade. It's no surprise that sooner or later people would start believing it.

View on HN

In all fairness, postgres still works for their workload even if RDS didn't. You can get a lot of workloads out of postgres with the right hardware, the right replication, and the right extensions (eg Citus has a columnar extension that probably would have been a pretty good fit for that).

To be fair, we're in an age with servers that can handle hundreds of simultaneous threads on a single system with terabytes of RAM and storage faster than RAM a few generations back.

You can scale up a lot with a general purpose RDBMS like postgres on a single server, and a read replica today.

It's not perfect, or even ideal for many workloads or even all environments... But it probably can be good enough for most application needs.

It's knowing when it isn't, why it isn't, and what to use instead that counts in those instances. But I hold no blame for starting with what is probably one of the better known and understood solutions to start with.

Eh, it's a reaction against people making or reaching for the wrong tools or the right tools but at the wrong scale.

Postgres is very very good. The vast majority of use cases work with it with very minor effort. People would, in general, be better off investing in thoroughly understanding a general tool like postgres (or similar dbs, just pick one to learn, but there are reasons why you would pick postgres over, say, oracle).

There are still reasons to use more specialized DBs. But the push for postgres is because very often the people reaching for those specialized DBs do so in error.

20M rows is practically an in-memory dataset, for example.

Reply on news.ycombinator.com