Just Use Postgres: The 2020s Movement to Replace Specialized Datastores

The Just Use Postgres movement is the position that PostgreSQL should be the default datastore for new projects and that specialized systems should only be added when an engineer can name a specific requirement Postgres cannot meet. Roughly eight replacement patterns are commonly cited: 1. JSONB with a GIN index replaces document stores like MongoDB. The JSONB type has been production-grade since 2014. MongoDB still wins on horizontal sharding and document-level replication, but for most workloads JSONB is sufficient. 2. `SELECT ... FOR UPDATE SKIP LOCKED` replaces Redis or RabbitMQ as a job queue, handling roughly 1,000 to 10,000 jobs per second per worker. Elixir's Oban library is built on exactly this pattern. Dedicated brokers still win for the 100k+ jobs/sec regime. 3. `tsvector` plus `tsquery` plus the pg_trgm extension for trigram fuzzy matching replaces Elasticsearch for most search workloads. Instacart famously moved off Elasticsearch onto sharded Postgres and reported roughly 80 percent cost reduction. Elasticsearch still wins for distributed log aggregation and faceted search at massive scale. 4. pgvector with HNSW indexes replaces Pinecone for collections under roughly 10 million vectors. The pgvectorscale extension, which adds a DiskANN-based index, has published benchmarks showing 28x lower p95 latency and 16x higher throughput than Pinecone at 99 percent recall, scaling up to around 100 million vectors. A notable caveat: pgvectorscale is not available on AWS RDS. 5. PostGIS with GIST indexes is the uncontested standard for geospatial data and has been for two decades. 6. Declarative partitioning combined with BRIN indexes replaces dedicated time-series databases for many workloads. A BRIN index only stores min and max values per physical block, making it tiny — kilobytes where a B-tree would use gigabytes — but it only works for data inserted in roughly sorted order. TimescaleDB is the upgrade path when the basics run out. 7. Materialized views with `REFRESH CONCURRENTLY` replace small data warehouses for dashboard use cases. They pre-compute aggregations and the concurrent refresh does not block readers. 8. PostgREST or `pg_graphql` combined with row-level security replace much of a custom API layer by auto-generating REST or GraphQL endpoints directly from the schema. Supabase is the productized version of this pattern. The core argument is not that Postgres beats every specialized system on its own benchmark — it usually does not — but that the operational, cognitive, and consistency benefits of one system are large, and Postgres is now close enough on enough axes that most teams under roughly 10 million users and 1,000 QPS never need to move off it.