How does Postgres stack up against columnar databases like Vertica and DuckDB for analytical queries?

Gad, they sure like to say "BM25" over and over again. That's a near worthless approach to result ranking. Doing any halfway ok job requires much more tuned and/or more powerful approaches.

It irks me that these "just use Postgres" posts only talk about feature sets with no discussion about operations, reliability, real scaling, or even just guard rails and opinions to deter you from making bad design decisions. The author writes about how three nine's is multiplied over several dependencies, but that's not how this shakes out in practice. Your relational database is typically far more vulnerable than distributed alternatives. "Just use Postgres" is fine advice but gets used as a crutch by companies who wind up building everything in-house for no good reason.

I have two fundamental problems with Postgres - an excellent piece of technology, no questions about that.

First, to use Postgres for all those cases you have to learn various aspects of Postgres. Postgres isn't a unified tool which can do everything - instead it's a set of tools under the same umbrella. As a result, you don't save much from similarly learning all those different systems and using Postgres only as a RDBMS. And if something isn't implemented in Postgres better than in a 3rd party system, it could be easier to replace that 3rd party system - just one part of the system - rather than switching from Postgres-only to Postgres-and-then-some. In other words, Postgres has little benefits when many technologies are needed comparing with the collection of separate tools. The article notwithstanding.

Second, Postgres is written for HDDs - hard disk drives, with their patterns of data access and times. Today we usually work with SSDs, and we'd benefit from having SSD-native RDBMSes. They exist, and Postgres may lose to them - both in simplicity and performance - significantly enough.

Still, Postgres is pretty good, yes.

The only thing postgres lacks is a distributed option.

Postgres can definitely handle a lot of use cases; background job scheduling always had me tempted to reach for something like rabbitmq but so far happy enough with riverqueue[0] for Go projects.

[0]: https://riverqueue.com/

I have a colleague who (inexplicably) doesn't trust Postgres for "high performance" applications. He needed a database of shared state for a variable number of running containers to manage a queue, so he decided to implement his own bespoke file-based database, using shared disk. Lo and behold, during the first big (well-anticipated) high-demand event, that system absolutely crawled. It ran, but it was a total bottleneck during two days of high demand. I, who has made a New Years resolution to no longer spend political capital on things that I can't change, looked on with a keen degree of schadenfreude.

Just. Use. Postgres.

Meh, it's 2026! Unless you're Google, you should probably just pipe all your data to /dev/null (way faster than postgres!) and then have a LLM infer the results of any get requests

This post is discussing more specialized databases, but why would people choose Oracle/Microsoft DB instead of Postgres? Your own experience is welcome.