In 2026, use Postgres — until requirements say otherwise

Think of your database like a house. Living room, bedroom, kitchen, garage — each room has a purpose, but they all live under the same roof. You don't build a restaurant across town because you need to cook dinner. You don't rent a commercial garage to park your car.

Postgres works the same way. Search, vectors, time-series, queues, documents — different rooms, one house. Same roof, same foundation, same key.

The argument isn't mine — it's the thesis of "It's 2026, Just Use Postgres", published by the Tiger Data team (creators of TimescaleDB) on HackerNoon. Read the original in full, but here's my take on why the thesis got even stronger now that agents are in the loop.

The "right tool for the job" trap

The database industry sells a cliché: "use the right tool for the right job." Sounds wise. Also sells a lot of databases.

You follow the advice and end up with:

Elasticsearch for search
Pinecone for vectors
Redis for caching
MongoDB for documents
Kafka for queues
InfluxDB for time-series
Postgres for whatever's left

Congratulations: seven databases to run. Seven query languages, seven backup strategies, seven security models, seven monitoring dashboards — and seven things that can break at 3 AM.

When something actually breaks, good luck reproducing it in a test environment. You'll need synchronized snapshots across all seven systems, at the same point in time, all running on your laptop. Let us know how that goes.

The AI era changed the math

"Consolidate everything in Postgres" isn't a new argument. What changed in 2026 is who's asking for the database: AI agents.

Think about what an agent needs to do to fix a production bug:

Spin up a test database that looks like production.
Try a fix.
Verify it.
Tear everything down.

With one database, that's a single fork command.

With seven, the agent has to coordinate snapshots across each system, spin up seven services, configure seven connection strings, hope nothing drifts during the test, then tear it all down. That's not an inconvenience — that's a research project.

It's no accident that most coding agents today silently assume a single-database architecture. The same logic applies to the on-call engineer reproducing an incident, to any CI pipeline that wants realistic data, and to every team that wants to experiment safely.

Database consolidation used to be an architectural preference. In the agent era, it's becoming a functional requirement.

The secret: the algorithms are the same

Here's what specialized-database vendors don't want you to think too hard about:

What you need	Specialized tool	Postgres extension	Same algorithm
Full-text search	Elasticsearch	`pg_textsearch`	BM25
Vector search	Pinecone	`pgvectorscale`	HNSW / DiskANN
Time-series	InfluxDB	`TimescaleDB`	Time partitioning
Documents	MongoDB	`JSONB`	Document indexing
Caching	Redis	`UNLOGGED tables`	In-memory storage
Queues	Kafka	`pgmq`	Message queuing
Geospatial	Specialized GIS	`PostGIS`	Industry standard since 2001

And it's not theoretical:

pgvectorscale delivers 28× lower p95 latency and 16× higher throughput than Pinecone at 99% recall on a 50M-vector benchmark.
TimescaleDB matches or beats InfluxDB on time-series workloads — with full SQL, JOINs, and ACID guarantees.
pg_textsearch runs the same BM25 ranking that powers Elasticsearch.

Postgres extensions aren't experiments. PostGIS has been in production since 2001. TimescaleDB since 2017. pgvector since 2021. Over 48,000 companies run Postgres — including Netflix, Spotify, Uber, and Discord.

When the specialist still wins

The honest read: there's a small slice of cases where the specialized tool still beats Postgres. The "when you still need the specialist" column of the original post is what matters:

Kibana + complex nested aggregations + petabyte-scale search → Elasticsearch.
Managed multi-tenant sharding at billions of vectors → Pinecone.
Pure-metrics environment with no relational data → InfluxDB.
Fully schemaless data model + change-streams ecosystem → MongoDB.
Pub/sub, sorted sets, Lua scripting, sub-millisecond latency on complex structures → Redis.
Cross-datacenter event streaming with consumer groups → Kafka.

These are requirements you feel because you hit a concrete wall — not because marketing told you to "plan for the future."

The costs nobody adds up

Even when a specialized database wins on a specific benchmark, you pay for it across every other dimension:

Cognitive load. Your team needs SQL + Redis commands + Elasticsearch Query DSL + Mongo aggregation pipelines + Kafka consumer patterns + InfluxDB's query language. That's not specialization — that's fragmentation.

Consistency. Keeping Elasticsearch in sync with Postgres means building sync jobs. They fail silently. Data drifts. You add reconciliation. Reconciliation fails too. Now your team maintains data plumbing instead of shipping the product the company actually sells.

SLA math. Three systems at 99.9% combine into 99.7%. That's 26 hours of downtime per year, not 8.7. Every new system multiplies the failure surface.

Real cost. Plexigrid consolidated from four databases to one and got 350× faster queries. Flogistix cut database costs by 66%. Latitude saved $12K/month on compression alone.

Where Postgres truly shines

Before the limits, let's nail down where it's the obviously right choice — something well distilled in this video on Postgres's limits in distributed systems:

Monoliths and small-to-mid apps — the classic "corner-shop, pharmacy, or small-market app." One environment, one database, zero multi-node complexity. That's the overwhelming majority of real systems.
Single node — when app and database live on the same server (or a few), and there's no need for sharding, Postgres flies.
Consistency + structured data (CA) — in CAP, being CA is an advantage when you don't need partition tolerance. You get solid relationships, ACID transactions, and strong consistency without paying the distributed tax.
Read-heavier than write — the natural evolution via read replicas (master for writes + replicas for reads) solves the initial bottleneck simply, with ordinary ORMs, without rewriting the architecture.
Early projects and familiarity — it's the default relational database almost every dev knows. Easy to spin up, covers most needs for teams that are just starting to scale.

In one sentence: Postgres shines when global scale and network partitions aren't your problem — which is the reality of nearly every product before it becomes an Uber or a Nubank.

The other side: where Postgres hits a wall

Consolidating on Postgres is the right bet for most systems — monoliths and small-to-mid apps. But it'd be dishonest to stop here without naming the real limit: Postgres was born as a single-node database, and that shows the moment a system needs to be genuinely distributed at large scale.

1. CAP theorem — no partition tolerance. In CAP terms, Postgres is a CA database (Consistency + Availability): it wasn't built to guarantee network partition tolerance (P). Since every distributed system must deal with partitions, Postgres isn't the natural pick when the topology is multi-node by design.

2. Write bottleneck (master-replica). The standard way to scale is read replicas: one master absorbs writes, several replicas serve reads. Great for read-heavy workloads — but the master stays the single write point. Under heavy write volume, it becomes the bottleneck.

3. Sharding is manual and painful. Databases like Cassandra shard (fragment data across nodes) automatically and natively. In Postgres, distributing data across shards is manual and complex — you end up writing routing logic to know which node holds which data. Extensions like Citus help, but that's an extra layer, not native behavior.

4. The replication trade-off is brutal.

Synchronous → guarantees consistency, but if the network partitions, the database can't confirm the write across all nodes and your app goes unavailable.
Asynchronous → improves performance, but opens up eventual consistency: a user can read stale data right after an update. Unacceptable in domains like banking.

5. Cost. Forcing Postgres to run distributed at scale (e.g., multi-AZ RDS on AWS, beefy instances) can get expensive — sometimes more expensive than a database that was built distributed from day one.

Databases like Cassandra (quorum) or MongoDB (Raft for election/replication) ship these mechanisms in the core. Postgres doesn't — and adapting it charges a disproportionate technical and financial price when you're genuinely in that regime.

The honest question: are you actually in that regime? Most aren't. "Distributed at large scale" is often an architectural prophecy that never comes true — and the cost of preparing for it too early is precisely the fragmentation this post argues against. But if you run global writes, multi-region with guaranteed partitions, or consistency-under-network-failure as a hard requirement — then Postgres's single node is a real wall, not marketing.

And when it's banking/fintech? What to use

In banking and financial apps, the priority is non-negotiable: strong consistency. Every node must see the latest data. Eventual consistency here is a defect, not a trade-off — picture repeated transfers fired against a stale balance. When the regime is distributed and critical, these are the candidates:

CockroachDB — distributed relational database that speaks the Postgres protocol and uses Raft internally to guarantee strong consistency at scale. The natural replacement for teams who love Postgres but need real distribution.
Google Spanner — the "monster" of the category: atomic clocks + TrueTime deliver external consistency at global scale, resolving concurrency down to the microsecond. Expensive and GCP-locked, but unmatched when that's the requirement.
MongoDB — often remembered for performance only, but in PACELC it's PC/EC (prioritizes consistency both during a partition and in normal operation) and offers ACID transactions. Viable for financial data when configured properly.
Cassandra with quorum — by nature it's AP/EL (availability and low latency), but it's versatile: setting the consistency level to QUORUM or ALL at query time forces a majority/all of the nodes to confirm before responding — enough for critical scenarios.

Notice what's not on that list by default: Postgres. Not because it's bad — the opposite of what this post argues. It's an excellent single node; it just lacks native partition tolerance and automatic sharding to back a distributed, global banking core without expensive manual work. For a small-to-mid fintech, a monolith, or a regional bank, Postgres is still great. For a planet-scale transactional core, pick a tool built for it.

First of all: no requirements, no architecture

Notice that every decision above — consolidated Postgres, distributed, banking core — comes not from fashion or the hype of the database du jour. It comes from requirements.

Without requirements, there's no architecture.

It's the one rule that precedes all the others. "CA or AP?" isn't an aesthetic preference — it answers "do I need to tolerate network partitions?". "Postgres or CockroachDB?" answers "do I have global multi-region writes?". "One database or seven?" answers "what problem do I actually have today?".

Choosing a database before gathering requirements is guessing — and expensive guessing, because architecture errs upward (complexity you carry forever) or downward (a wall that takes you down in production). The most common sin, and the one this post fights, is architecting for an imaginary future requirement.

The practical rule

Start with one database. Add complexity only when you've earned the need for it.

Postgres with the right extensions handles search, vectors, time-series, documents, caching, queues, geospatial, and scheduled jobs. The algorithms match their specialized counterparts. The extensions are battle-tested. And operational simplicity compounds every month you don't add another system.

Most teams adopt a specialized database before testing whether Postgres can handle the workload. They add Elasticsearch because "that's what you use for search," not because they tried pg_textsearch and found it lacking. They add Redis because "everyone uses Redis for caching," not because UNLOGGED tables couldn't handle their load.

The "right tool" advice sounds wise. Too often, it's a solution to a problem you don't have yet — sold by the people who profit from you having it.

Test the assumption first. Then decide.

TL;DR: In 2026, "boring tech" won — and Postgres is at the center. Before adding another database to your stack, read the original post from Tiger Data and check if an extension already solves it. Your team, your agents, and your on-call engineer will thank you.