Just Use Postgres

A few years back I inherited a system that had Postgres, Redis, MongoDB, Elasticsearch, and RabbitMQ. Five different data stores. For what was, at its core, a CRUD app with some search and background jobs.

Each one was added to solve a specific problem. Each one made sense at the time. And each one was another thing that could break at 3am, another thing to monitor, another thing nobody fully understood anymore.

I’ve watched a lot of architecture meetings go sideways since then. Someone’s building a new feature. They need to store some data. And the questions start.

“Should we use MongoDB for this? The data is kind of document-shaped.”

“We need caching. Let’s add Redis.”

“This needs full-text search. Elasticsearch?”

“We’ve got some background jobs. Maybe we need RabbitMQ.”

Here’s my answer to almost all of these: just use Postgres.

The everything database

Postgres isn’t just a relational database anymore. I mean, it is—it’s excellent at that. But it’s also absorbed so many features over the years that it can replace half your infrastructure.

JSON? Postgres has had jsonb since 2014. You can store documents, query into them, index them. It’s not MongoDB, but for 90% of use cases it’s plenty.

Full-text search? Built in. tsvector, tsquery, ranking, stemming, multiple languages. It’s not Elasticsearch, but unless you’re building actual search infrastructure, it’s probably enough.

Caching? UNLOGGED tables are fast. Materialized views refresh on demand. And honestly, your database is probably faster than you think—benchmark before you add Redis.

Queues? LISTEN/NOTIFY for pub/sub. SELECT ... FOR UPDATE SKIP LOCKED for job queues. pg_boss, Graphile Worker, PGMQ if you want something more structured. All just Postgres.

Cron jobs? pg_cron. Runs inside the database. No external scheduler needed.

Time series? TimescaleDB is just a Postgres extension.

Geospatial? PostGIS. The industry standard. Also just an extension.

You get the idea.

Why fewer moving parts matter

Every piece of infrastructure you add is something that can fail. Something you have to monitor. Something you have to upgrade. Something your team has to understand.

Redis goes down at 3am? Now you’re debugging cache invalidation while half-asleep. RabbitMQ gets backed up? Hope you understand AMQP. Elasticsearch cluster goes yellow? Better know what shard allocation means.

Or: you just have Postgres. One database. One connection string. One backup strategy. One thing to keep running.

I’m not saying Postgres never fails. But you’re already running it for your main data. You already know how to operate it. You already have backups. Adding features to the thing you’re already running is almost always simpler than adding new things.

When it’s not enough

Look, I’m not religious about this. Sometimes you actually need the specialized tool.

If you’re doing millions of cache reads per second, yes, use Redis. If you’re building Google-scale search, yes, use something built for that. If your queue needs are complex enough that you’re thinking about dead letter exchanges and message TTLs, maybe you do want RabbitMQ.

But be honest about whether that’s you. Most of us aren’t building at that scale. Most of us are building CRUD apps with some background jobs and maybe some search.

For that? Just use Postgres.

The real reason people don’t

Adding infrastructure feels productive. It feels like engineering. You get to learn a new tool. You get to put it on your resume. You get to architect something.

Using Postgres feels boring. It’s the database you already have. There’s nothing new to set up. No exciting technology to evaluate.

But boring is good. Boring means fewer surprises. Fewer 3am pages. Fewer “how does this work again?” moments when you’re debugging production.

The best infrastructure is the infrastructure you don’t have to think about. And the less of it you have, the less there is to think about.

It’s the same reason the Unix philosophy keeps winning—stable, boring interfaces beat shiny new ones over time. Postgres has been around since 1996. The SQL you wrote ten years ago still runs. Try saying that about your favorite NoSQL database.

What’s your “just use X” technology? The boring choice that keeps working? I’d like to hear about it.