Every few months, a new database shows up on Hacker News promising to solve all your problems. It's faster. It's simpler. It scales to infinity. You should probably just use PostgreSQL.
It does everything
PostgreSQL isn't just a relational database. It's a JSON document store (with jsonb). It's a full-text search engine (with tsvector). It's a time-series database (with partitioning). It's a geospatial database (with PostGIS). It's a pub/sub system (with LISTEN/NOTIFY). It's a job queue (with SKIP LOCKED).
Most applications need exactly one database. PostgreSQL is that database.
The "but MongoDB" argument
People reach for MongoDB because they think their schema is "flexible." In practice, schema flexibility means "we haven't thought about our data model yet." That's not a feature — that's a problem.
PostgreSQL's jsonb columns give you the same flexibility when you actually need it, without giving up transactions, joins, or 30 years of battle-tested reliability. You get the best of both worlds.
The "but it doesn't scale" argument
PostgreSQL handles thousands of concurrent connections and millions of rows with proper indexing. The Boulangerie project I built serves its entire product catalog, cart system, and order management from a single PostgreSQL instance.
Unless you're processing billions of events per day, you don't need a distributed database. You need proper indexes, connection pooling, and maybe a read replica. All of which PostgreSQL handles natively.
When PostgreSQL isn't enough
I'm not saying it's the answer to everything. If you need a cache layer, use Redis. If you need full-text search at massive scale, Elasticsearch is purpose-built for that. If you're building an analytics platform processing terabytes daily, look at ClickHouse or BigQuery.
But for your web app, your API, your SaaS product? PostgreSQL. Every time. It's free, it's fast, it's reliable, and it'll outlast whatever trendy database just launched on Product Hunt.
The boring choice wins
I've been on projects that used five different databases because each one was "the best tool for the job." You know what they actually got? Five different failure modes, five different backup strategies, and five times the operational complexity.
Pick PostgreSQL. Learn it well. Use it for everything you can. Add other tools only when PostgreSQL genuinely can't do what you need. You'll be surprised how rarely that happens.