We Still Pick Postgres in 2026. Here's the Boring Reason.

A year ago I was on a thread arguing that Postgres-by-default was a sign of unimaginative engineering. The argument went: there are now real alternatives — Convex, Turso, Supabase's edge story, Cloudflare D1 — and reaching for Postgres in 2026 is the same as reaching for jQuery in 2018. Old habits.

I no longer believe this. Or rather, I believe the alternatives are real and I still pick Postgres for more than half of what we ship. The reason is not that I've stopped enjoying new tools. The reason is that "boring" turns out to mean something more specific than I appreciated, and that the specific thing it means is valuable.

This is the case for Postgres in 2026 from someone who genuinely uses the alternatives.

What "boring" actually buys you

The Stack Overflow developer survey last year had Postgres at 55.6% adoption among professional developers — the most used, most desired, and most admired database for the third year running. Those numbers are a lagging indicator. The thing they measure is a kind of gravitational pull that compounds over decades.

Concretely:

The training data is enormous. Every AI coding tool is going to produce more reliable output for a Postgres schema than for a newer database, because the training corpus is twenty years deep. If you ask Claude for an index strategy on a Postgres table, the answer is going to be load-bearing. If you ask it for the same on a database that's been around for two years, the answer will be plausible but you should verify it.

The failure modes are documented. Every weird thing your Postgres deployment can do — connection pool exhaustion, vacuum freezing, plan flips after a stats update — has been written about. By a DBA. With a stack trace. On a blog from 2014 that's still up. When something goes wrong at 2 AM, the cost of "I have never seen this before" is high; the cost of "this happened to thousands of people in 2018" is much lower.

The ecosystem is silly. Sixteen years of extensions. Vector search via pgvector. Logical replication. Foreign data wrappers. TimescaleDB. PostGIS. Every weird thing you might need exists, has been used in production by someone bigger than you, and has documentation.

The hosting market is competitive. Neon. Supabase. RDS. Aiven. Crunchy. Fly. Your hosting bill is contested, which means the price is reasonable, and you can switch without rewriting your application because the surface is SQL.

None of this is exciting. All of it compounds in your favor every quarter.

When we don't pick Postgres

For two of our products — Wryte and OurTrail — we're on Convex, and I wrote a separate post about why. The short version: those apps are real-time-first, with subscriptions that the platform handles natively. Building that on Postgres would mean either writing a WebSocket layer ourselves or pulling in a separate listen/notify infrastructure. The cost there exceeded the cost of Convex's lock-in.

For an internal admin tool with three users, we use SQLite on a single box. Postgres would be overkill; we don't need concurrent writers at scale.

For a future product where we know we need vector search, we'll also be on Postgres, because pgvector exists and is good. The "future-proofing for AI" argument that some people make against Postgres ("won't you need a vector database?") is mostly answered by extensions already shipping in Postgres.

When we do pick Postgres

The framing we use, when we start a new project, is a flowchart with three questions.

Does this app have inherently real-time multi-user semantics? If the canonical experience requires that user A sees user B's writes within a second, on a screen that's already open, then we lean toward a reactive backend. Otherwise we default to request/response.

Does this app have a clear domain model that fits relational rows? Almost every CRUD-shaped app does, even apps that don't think they do. If the data is people, things, and the actions they take, it's relational. If you find yourself trying to model "documents with arbitrary nested schemas," consider that JSONB exists and Postgres still gives you indexed queries inside it.

Do we need to operate this in five years? Not all products do. The ones that do, we want on a substrate we can run anywhere, with a query language that hasn't changed materially since 1995. Postgres makes that question easy to answer.

If all three answers point toward Postgres — which is most of the time — we go with Postgres. Boring. Done. The interesting decisions are upstream.

The "but Postgres can't do X" objections

Two come up often.

"Postgres can't scale to millions of users on a single instance." Correct. It can scale to millions of users on a sharded or read-replica'd setup, which is what every Postgres-backed company of any size has built. The transition from single-instance to scaled is not free, but it's also one of the most thoroughly documented operational journeys in the industry. We will worry about this when our user count requires it; we have not seen a single founder regret being on Postgres at that point.

"Postgres doesn't do real-time." It does, sort of, via LISTEN/NOTIFY. It's not as ergonomic as a reactive backend. If real-time is core to your product, this is the case where you do pick something else. For the majority of products, "the page updates when the user refreshes" or "we poll every 5 seconds for the dashboard" is the actual requirement, even when the team thinks it's "real-time."

The deeper point

The conversation about databases tends to be framed as if there's a march of progress and you choose where on the timeline you want to stand. There is no march. There are tools with different shapes, and the right choice depends on the shape of your problem.

What's true in 2026 that wasn't quite as true in 2020 is that the cost of a wrong choice has gone up, because both ends of the spectrum have become more capable. A reactive backend will solve real-time-first problems beautifully and make a CRUD app feel weird. A relational database will solve almost everything else and require you to write a separate real-time layer if you need one.

The question worth asking — before you reach for whichever you reach for by reflex — is: "what is the shape of the data this app exists to manage?" If the answer is "structured, multi-table, the relationships are the whole point," that's a Postgres app. The other answers exist; they are not most answers.

Picking Postgres in 2026 is not a vote against the new tools. It's a recognition that for most of the problems most teams are solving, the boring thing is still the right thing, and the cost of being wrong is lower in the direction of the boring thing. We use the exciting tools where they fit. We pick Postgres everywhere else, and we sleep fine.

---

References: PostgreSQL is the most-used and most-admired database in the 2025 Stack Overflow Survey. Long live boring technology.