PostgreSQL is enough
Advocates of “Postgres for everything” argue that the database is so feature‑rich and extensible—covering queues, pub/sub, vector search, analytics, and more—that many teams can simplify their stack and postpone adding specialized services like Redis, Kafka, or Elasticsearch. Critics counter that pushing too much logic and too many workloads into Postgres harms ergonomics, makes debugging and migrations painful, and eventually runs into scaling or HA limits, at which point dedicated tools or alternative databases become necessary. Across viewpoints, there is broad agreement that Postgres is an excellent default for OLTP and small‑to‑medium systems, but that architecture should evolve with scale, workload characteristics, and team expertise rather than chasing a single “one size fits all” solution.
Role of Postgres in the Stack
- Many see Postgres as an excellent default: powerful, extensible, “good enough” for most CRUD apps and for a long time as scale grows.
- Others argue “one size fits all” is unrealistic: relational DBs aren’t ideal for every workload (heavy OLAP, streaming, massive metrics, etc.).
- Several stress that what’s appropriate for a 1‑person startup is not what’s appropriate for a large company; it’s fine to change tools over time.
Queues, Pub/Sub, and Background Jobs
- Postgres as a message queue is widely used and liked (e.g., queues built on tables,
LISTEN/NOTIFY, WAL consumers). - Benefits highlighted: transactional enqueue with DB updates, simpler infra vs adding SQS/Rabbit/Kafka; can get “exactly-once” semantics within DB transactions.
- Critiques: exactly‑once outside the DB is impossible in general; SQS and other managed queues bring scale and reliability but add IaC, access control, monitoring, and cognitive load.
Pushing Logic into the Database
- Pro side: business logic in stored procedures/triggers can be much faster than app code, closer to the data, and can simplify failure handling.
- Con side: poor DX and tooling (debugging, testing, code review, versioning); triggers make behavior invisible from app code and hard to reason about; upgrades become more fragile.
- Several recommend a middle ground: use DB for constraints, validation, and simple table-local behavior; keep process orchestration in the app.
SQLite vs Postgres
- Some advocate “start with SQLite” for MVPs: single file, embedded, trivial setup, fast for many small apps, good for local/offline use and tests.
- Others respond that Postgres setup is also easy and avoids painful DB swaps later, especially once there’s real data and concurrency.
- Debate around the “N+1 query problem”: one side claims SQLite largely avoids the pain due to in-process calls; others argue N+1 is a modeling/query issue, independent of engine.
Scaling, Multi‑Tenancy, and HA
- Postgres can handle very high throughput on modern hardware; many apps never outgrow a single server.
- Still, HA clustering and horizontal scaling are seen as non‑trivial; people mention sharding, per‑tenant DBs, and Postgres derivatives/extensions (e.g., distributed or cloud offerings).
- Multi‑tenant setups (per‑customer DB or sharded by customer) are common patterns; large single multi‑tenant schemas can become painful.
JSON, Vectors, and Specialized Workloads
- Postgres JSON/JSONB is praised, but others warn about performance and denormalization pitfalls; recommendation: use JSON sparingly, not as an excuse to avoid schema design.
- For metrics and time series, TimescaleDB and similar extensions are suggested; for very large or real‑time OLAP/metrics, specialized systems (ClickHouse, StarRocks, VictoriaMetrics, etc.) are preferred.
- Vector search: Postgres extensions (e.g., pgvector, related tooling) exist and are suitable for smaller workloads; at very large scales, dedicated vector DBs may be better.
Operational Complexity and Technology Choice
- Strong theme: every extra dependency is a liability (complexity, security, maintenance). Stretching Postgres you already run is often cheaper than adding new services.
- Counter‑theme: overloading Postgres makes it a single bottleneck and can lead to “twisty” architectures (HTTP from triggers, heavy listen/notify, etc.).
- Many advocate “choose boring tech,” avoid resume‑driven shiny tools, but also avoid turning Postgres into the only hammer.