Postgres won, and the interesting question is what that costs

The database argument is largely over. PostgreSQL sits at 55.6% developer adoption and remains the most-wanted database in survey after survey, with something like 65% of developers reaching for it on new projects.

PostgreSQL 18 has been stable since 13 August 2026, and 19 is in beta with two changes that matter: a 64-bit transaction ID that would finally retire the wraparound problem, and pgvector indexing moving toward core.

When a tool wins this decisively, the useful posture is not celebration. It is asking what the default is costing you, because nobody audits a default.

The vector consolidation is the real story

For two years the standard architecture for anything with semantic search involved a dedicated vector database alongside your primary store. That meant two systems, two consistency models, and a synchronisation problem nobody enjoyed owning.

Postgres with pgvector collapses that into one system for a large class of workloads. Your embeddings live next to the rows they describe. You can filter by tenant, date and status in the same query that does the similarity search, transactionally, without reconciling two sources of truth.

This is a genuinely large simplification, and it is the reason a great many purpose-built vector databases are having a difficult year.

It is not free. Dedicated vector stores are faster at very high vector counts and offer index types Postgres does not. The honest threshold is roughly this: below a few million vectors with meaningful metadata filtering, Postgres is almost certainly the right answer and the specialised system is a second thing to operate. Above that, with pure similarity search at high queries per second, the specialist earns its place.

Most teams are far below that line and were sold the specialist anyway.

What "it's just Postgres" hides

Winning by default has a predictable failure mode: teams stop making decisions and start assuming.

Extensions are your dependency surface. pgvector, PostGIS, pg_partman, TimescaleDB — the extension ecosystem is the reason Postgres absorbed so many workloads, and each one is a component with its own release cadence and upgrade constraints. "We run Postgres" and "we run Postgres plus six extensions" are meaningfully different operational statements, particularly at major-version upgrade time.

Connection handling is still the classic footgun. Postgres uses a process per connection. A serverless platform that opens a connection per invocation will exhaust the server long before it exhausts anything else. Connection pooling is not an optimisation; for that architecture it is a requirement, and it is the single most common way a Postgres deployment falls over under load.

Managed does not mean unmanaged. The managed Postgres market is growing quickly, and it removes a real burden. It does not remove your responsibility for schema design, index bloat, long-running transactions holding back vacuum, or a query plan that quietly changed after the statistics did.

The upgrade worth watching

The 64-bit transaction ID in the 19 line deserves attention beyond the usual release-note skim. Transaction wraparound is one of the few Postgres failure modes that can take a busy database down hard, and it has claimed enough production systems over the years to be genuinely feared. Retiring the 32-bit counter removes a class of incident rather than mitigating it.

If you run a high-write workload, that is the change to plan a migration around.

The general point

There is a version of technology choice that consists of picking whatever most people picked. It usually produces adequate outcomes, which is why it persists.

Postgres being the right default for most applications is, as far as I can tell, true. But "most applications" is doing real work in that sentence, and the teams that get burned are the ones who took the default and then stopped thinking about connection limits, extension upgrades, and where their vector workload actually sits relative to the threshold where the simple answer stops being the correct one.

A default you have examined and kept is a decision. A default you inherited is a bet you have not priced.