Serge BelovThe database landscape has fragmented dramatically over the past decade. There's a database for every use case — document storage, time series, graph relationships, full-text search, vector embeddings. Teams often reach for specialized tools early, adding operational complexity before they've exhausted what a general-purpose database can do.
PostgreSQL handles more than most teams realize. For the majority of applications, it's the right choice at every stage of growth.
What PostgreSQL does well
Relational data with full ACID guarantees. The core case. PostgreSQL is one of the most reliable, mature relational databases available. Its consistency guarantees make it appropriate for financial data, inventory, user records — anything where correctness matters.
JSON and semi-structured data. JSONB columns let you store schema-flexible data alongside relational data in the same database. Teams reach for MongoDB because they want schema flexibility. PostgreSQL gives you that without sacrificing joins, transactions, or full SQL.
Full-text search. Built-in full-text search with tsvector and tsquery handles most search requirements. Not Elasticsearch-level at scale, but sufficient for the majority of applications — without running a separate service.
Vector search with pgvector. The pgvector extension adds vector similarity search, which is the core capability required for AI/RAG applications. You don't need a separate vector database for most AI features.
Time series data. The TimescaleDB extension (or even native PostgreSQL with partitioning) handles time series workloads that would otherwise push teams toward InfluxDB or similar.
When PostgreSQL isn't enough
Specialized databases become necessary at scale or with specific requirements PostgreSQL genuinely can't meet:
- Elasticsearch — for advanced search features: faceted search, relevance tuning, analytics at scale
- Redis — for sub-millisecond caching and pub/sub patterns (PostgreSQL LISTEN/NOTIFY works for moderate use)
- A dedicated vector database — when vector search is the primary workload at high scale
- A time series database — when ingesting millions of events per second with complex retention policies
These are real use cases. They're also not where most teams start.
The operational argument
Every database you add is infrastructure you operate: backups, monitoring, scaling, failover, credentials management, cost. PostgreSQL consolidates as many workloads as possible into a single, well-understood system.
One well-configured PostgreSQL instance with proper indexes, connection pooling (PgBouncer), and read replicas will serve most applications to millions of users. The teams that reach for exotic infrastructure early often do so for reasons that have more to do with engineering interest than product requirements.
Start with PostgreSQL
Default to PostgreSQL. Add other data stores when you hit a concrete limitation — not in anticipation of hypothetical scale. The cost of premature database complexity is real; the cost of migrating away from PostgreSQL when you genuinely need to is manageable and usually far in the future.