Apr 22, 2026
Most teams I've seen pull in a second database within their first six months. Redis for caching. Mongo for "flexible schemas." A queue for background jobs. Then they spend the next six months wiring it all together and debugging the seams.
Try Postgres first. Genuinely try.
Caching. A cached_responses table with a TTL column and a partial index is a perfectly good cache for read heavy data. If you're not at the scale where the cache eviction cost dominates your DB load, you don't need Redis.
Background jobs. A jobs table with a status enum, a SELECT ... FOR UPDATE SKIP LOCKED, and a worker loop is a job queue. It's transactional, observable, and you can debug it with SQL. I use this pattern in production at scale. It does not break.
Pub/sub. LISTEN and NOTIFY are built in. Real applications use this in production. Most teams have never heard of it.
Search. to_tsvector, GIN indexes, trigram extensions. Full text search good enough for tens of millions of rows before you need a dedicated search engine. The ecommerce platform I run falls back to Postgres FTS when Meilisearch isn't configured; nobody can tell the difference.
Schema flexibility. jsonb columns with GIN indexes give you Mongo style flexibility with relational discipline. You can query them. You can index them. You can constrain them when you're ready.
Scheduling. pg_cron or just a timestamp column and a worker. Most "scheduled job" systems are doing exactly this and charging you for it.
Geo. PostGIS is the geo system. The teams shipping geospatial features on Mongo are doing it the hard way.
The lesson isn't "never use another database." The lesson is this: Postgres is the floor of your stack, not the ceiling. Use it harder before you add to it. Every additional moving part is a thing that fails in production, a thing your new engineer has to learn, a thing your alerting has to cover.
The boring stack wins. Postgres is the most boring choice. That's why I keep reaching for it first.