Postgres won, and we should just say so
For the first time in the history of the Stack Overflow Developer Survey, Postgres passed MySQL as the most-used database among professional developers. That is not a press release. It is the center of gravity moving. A generation of engineers learned MySQL by default, the next one is learning Postgres by default, and defaults compound.
This was earned. Postgres spent two decades being the careful, correct, slightly less fashionable choice while it grew a feature set nobody else matched: real transactions, rich types, a planner you can actually reason about, and an extension ecosystem that turned it into a platform. The win is deserved. The interesting part is what a deserved win does to how people decide.
"Postgres for everything" is the new default
The reflex now is to put everything on it. Relational data, obviously. The job queue, with SKIP LOCKED. Vector search, with pgvector. Full-text search, with tsvector. Scheduled jobs, with pg_cron. The cache, because a table with a TTL column is right there. Even the analytics, because the data already lives in it.
I understand the pull completely, and most of the time I follow it. One database is one thing to run. The maximalist position has a real argument behind it, and the people making it are not wrong to start there. The trouble is that a default this strong stops feeling like a choice, and a choice you stop making is a choice you stop checking.
Most of that gravity is good
Consolidating on Postgres buys you things that are easy to undervalue until you have lived without them. You back up one system and restore one system. One mental model covers how queries behave under load. One connection story, one failover story, one set of metrics that everyone on the team already reads.
Every extra datastore you add is not just its own operational weight. It is a new seam between two systems that can disagree, a new thing to keep consistent, a new page at 3am for a component half the team has never touched. Keeping the count low is a genuine engineering virtue, and Postgres makes a low count realistic for longer than it used to be. That part of the trend is healthy.
Where the default quietly stops
The walls are real, and I have walked into most of them. A Postgres table makes a fine job queue at low volume and a lock-contention machine when you push real event-stream throughput at it, which is its own whole post. Past tens of thousands of messages a second with many independent consumers, you want a log instead of a table, and that is the day Kafka stops being overkill. pgvector is excellent at a hundred thousand embeddings and a different animal at ten million, where index build time and recall start to fight each other. Heavy analytical scans across tens of gigabytes will pin the same instance your transactions live on, while a columnar engine on its own box finishes the same work in a fraction of the time.
None of these are reasons to avoid Postgres. They are the thresholds where "Postgres can do it" and "Postgres is the right tool here" stop being the same sentence.
The cost of a monoculture reflex
The quiet danger of a strong default is not any single wrong call. It is what happens to the question. "Postgres can do it" is true often enough that it starts answering "should it" before anyone asks "should it" out loud. The reflex eats the decision.
There is a skills cost too. A team that has never run anything but Postgres meets its first message broker, its first search cluster, or its first columnar warehouse during an incident, under load, at the worst possible time to be learning something new. The monoculture feels simple right up to the moment it is not, and by then nobody in the room has the muscle memory for the alternative.
Winning is exactly when over-reach starts
Every tool that wins its category goes through this. The trait that made it the safe choice, ubiquity, is the same trait that turns it into the answer to questions nobody examined. Java got used for shell scripts. JavaScript got used for everything with a screen. Popularity is not the problem on its own. The problem is that popularity makes the reflex feel like prudence.
A default that strong needs a tripwire, or it silently becomes the answer to questions you never actually weighed. Granting that Postgres should be the starting point is easy. Granting it the right to skip the architecture conversation is how you end up running a streaming platform inside a relational database and calling it simplicity.
The rule: a default plus a written threshold
The fix is small, and it is a habit instead of a tool. When you reach for Postgres to do the non-relational thing, write down the number that means you have outgrown it, in the same document where you made the choice. The queue moves off Postgres above this sustained rate. Vectors leave when recall drops below this bar or the index build crosses this duration. Analytics get their own box once the nightly scan starts stealing latency from live traffic.
You do not have to act on those thresholds today. You only have to name them today, while you are calm and thinking clearly, instead of discovering them at 2am when the one decision left on the table is a panicked migration under an incident bridge.
What I actually do
I reach for Postgres first, the same as everyone else, because the gravity is right far more often than it is wrong. The difference is one paragraph in the design doc: what this Postgres-shaped solution actually is, and the measured signal that tells me it is time to move that one workload somewhere built for it.
Postgres winning is good news. It is a sharper, more capable default than the one it replaced, and most systems are better off starting there. A default is still a starting point, not a verdict. The teams that get the most out of this era will be the ones who kept asking the question the win made so easy to skip.
Comments (0)