I’m the first person to tell founders to just use Postgres. I’m also the first person to tell them when it’s actually not enough — and I’ve watched a few teams blow up because they didn’t notice the line moving.

“Just use Postgres” is right ninety-five percent of the time. It’s a great default. The trouble starts when the five-percent case sneaks up on you — when your workload quietly drifts into territory where Postgres alone is the wrong tool, and you keep adding indexes and materialized views in a slow, painful spiral. The signals are usually obvious in retrospect. They’re rarely obvious at the time.

The Signals That You’re in the Five Percent

Here’s what I look for when a team tells me Postgres is “starting to feel slow.” Most of the time, the answer is “your query plan is bad and you need an index.” But sometimes it’s one of these:

  • You’re storing more than a few million embeddings and your similarity search is the hot path
  • You need strict tenant isolation in a multi-tenant setup, and row-level security is starting to become a maintenance burden
  • Your full-text search has stopped being good enough — users complain about ranking, not speed
  • You’re writing high-cardinality time-series data faster than you’re querying it, and your tables are exploding
  • You’re doing geospatial work that goes beyond simple radius queries and PostGIS is buckling under your access pattern
  • You have analytics workloads competing with your transactional ones and the whole database is suffering for it

 

If you’re nodding at one of these, you’re probably in the minority of teams who genuinely need something else — but probably not the something you think.

What Most Teams Get Wrong

The mistake I see most often is that teams jump straight to “we need to switch databases” or “we need a microservice with its own data store.” Both are usually wrong, and both are very expensive to undo.

The right move is almost always smaller than that. In order of escalation:

Try a Postgres extension first. pgvector handles embeddings well past the point most people think. PostGIS handles serious geospatial loads. Tools like TimescaleDB layer on time-series capabilities without leaving Postgres. Most “we’ve outgrown Postgres” stories are actually “we didn’t know about the extension that solves this.”

Add a sidecar, don’t migrate. If extensions don’t cut it, the next move is a specialized read replica or sidecar — Elasticsearch or Typesense for search, ClickHouse for analytics, a vector database for very large embedding workloads. Your source of truth stays in Postgres. The sidecar handles the specialized workload. You sync data into it on a schedule or with a CDC pipeline.

Switch databases only when forced. Full migrations off Postgres are a year-long exercise even at small scale. They’re worth it occasionally — for genuine OLAP workloads, for very high write throughput on time-series, for niche workloads where the operational profile is fundamentally different. They’re rarely worth it for the reasons people propose them.

The Operational Cost Nobody Talks About

Every additional data store you add doubles your operational footprint. Backups, monitoring, schema migrations, on-call expertise, version upgrades — all of it has to be done for every database in your stack. At seed stage, where you have two engineers and one of them is on vacation, this matters more than any benchmark.

The hidden tax of “let’s add ClickHouse” or “let’s add a vector DB” is the engineer who now has to learn it, the runbook that doesn’t exist yet, and the alert that fires at 3 AM in a system nobody on the team has debugged before. Postgres has a deep enough community and tooling base that you can almost always find someone who has hit your problem before. New databases don’t.

The Question I Ask Before Adding Anything

When a team is convinced they need to add a second data store, I ask: “Could you get there with a Postgres extension, and have you tried?” About half the time, the answer is no. The other half, the team has tried and the extension genuinely isn’t enough. Both answers are useful. The first means we just saved ourselves a migration. The second means we know exactly what problem we’re solving when we add the new system.

Extensions first. Sidecars second. Migrations almost never. Your future on-call self will thank you.

Let’s Talk

If you’re staring down a “we’ve outgrown Postgres” decision and you want a second opinion before you commit a quarter of engineering time, that’s the kind of call I take all the time. Sometimes the answer is yes — and when it is, having a clear plan matters. Reach out and let’s figure out which side of the line you’re really on.