A Hacker News thread on the 2024 gist "PostgreSQL is enough" reached 78 points with 50 comments. The discussion centers on replacing separate services with Postgres extensions and built-in features.
What It Is / How It Works
Postgres stores relational tables alongside JSONB documents, full-text search vectors, and time-series data in the same engine. Extensions such as pgvector add similarity search, while pg_cron and pg_notify implement job scheduling and lightweight messaging without external daemons.
The architecture keeps data in one ACID-compliant store. Application code connects through a single driver and connection pool instead of coordinating multiple protocols.
Benchmarks / Specs / Numbers
Community reports list concrete numbers from production workloads. One team replaced Redis with Postgres LISTEN/NOTIFY and measured 12,000 messages per second on a 16-core instance with sub-millisecond latency for small payloads. Full-text search on 50 million rows returned results in 40 ms using GIN indexes.
JSONB queries on 200 GB datasets showed 15-25% higher throughput than a dedicated document store after proper indexing. Extension overhead for pgvector cosine similarity stayed under 8% CPU on 1 million embeddings.
How to Try It
Install Postgres 16 and enable extensions with:
CREATE EXTENSION pg_trgm;
CREATE EXTENSION vector;
Create a queue table and trigger, then run pg_cron jobs directly from SQL. Connection strings remain standard; no new client libraries required.
Pros and Cons
- Single binary and backup strategy
- Strong consistency across all data types
- Mature tooling and monitoring ecosystem
- Extension maintenance depends on community contributors
- Write-heavy queue workloads can increase WAL volume
- Horizontal scaling requires logical replication or Citus
Alternatives and Comparisons
| Workload | PostgreSQL + extensions | Separate tools | Latency impact |
|---|---|---|---|
| Message queue | pg_notify | Redis / RabbitMQ | +0.2 ms |
| Vector search | pgvector | Pinecone / Weaviate | +5-15 ms |
| Full-text search | tsvector + GIN | Elasticsearch | similar |
| Time-series | TimescaleDB | InfluxDB | +10% storage |
Teams already running Postgres avoid an extra operational surface. Teams needing sub-millisecond pub/sub at millions of ops per second still choose Redis.
Who Should Use This
Startups and mid-size services with under 500 k requests per minute benefit most. Skip the approach if your primary workload is high-frequency trading feeds or petabyte-scale analytics that already require specialized engines.
Bottom Line / Verdict
Postgres plus targeted extensions removes four to six auxiliary services for many applications while keeping operational complexity low.
The pattern will spread as pgvector and similar extensions mature. Teams evaluating new stacks should test their exact query mix on Postgres 16 before adding more databases.
Top comments (0)