Every few months, an engineer proposes adding a specialized database to our stack. MongoDB for documents. ClickHouse for analytics. Neo4j for graph queries. Elasticsearch for full-text search. The answer is always the same: can PostgreSQL do it? If yes, we use PostgreSQL.
This is not dogma. It is operational pragmatism. Every database we add is a new system to monitor, back up, secure, and understand. Every database is a new set of failure modes we have to plan for. Every database is another thing that can break at 3 AM.
PostgreSQL can do most of what the specialized databases can do, often well enough that the difference does not matter for our use cases. And the operational simplicity of running one database instead of five is worth more than the theoretical performance gains of choosing the "optimal" tool for every job.
What PostgreSQL can do
JSONB columns give us a document store. Materialized views and partitioning handle most analytics queries. Full-text search with tsvector works for 90% of search use cases. Recursive CTEs handle graph queries. TimescaleDB (which is just a PostgreSQL extension) handles time-series data.
None of these are as fast as the specialized database built for that specific use case. But they are fast enough, and they live in the same database as everything else. We can join document data with relational data with time-series data in a single query. We can back them all up with one pg_dump. We can replicate them all with one standby.
When PostgreSQL is not enough
There are workloads where PostgreSQL genuinely cannot compete. If you are running clickstream analytics on billions of events per day, you probably need ClickHouse. If you are doing real-time graph traversal on a social network with a billion edges, you probably need Neo4j.
But most applications—including ours—are not operating at that scale. And even when you think you are, you might not be. The number of companies that actually need a distributed database is much smaller than the number of companies using one.
The cost of complexity
Every additional database adds cognitive load. Engineers have to remember which data lives where, how to query it, how to back it up, and how to debug it when things go wrong. This is manageable for a large engineering team with dedicated infrastructure specialists. For a forty-person firm like ours, it is a tax we cannot afford.
We would rather spend that cognitive capacity understanding the client's business logic, optimizing the queries that actually matter, and building features that solve real problems. The database is infrastructure. It should be boring.
— Marco