Completed · 5/5
Why PostgreSQL?
A series on choosing PostgreSQL with numbers, case studies, and operational realities.
Open series hub★ TOPIC · PostgreSQL
PostgreSQL
Series-first coverage of PostgreSQL architecture, operations, and ecosystem topics.
Featured Series
Good Starting Posts
Completed · 5/5
Why PostgreSQL?
A series on choosing PostgreSQL with numbers, case studies, and operational realities.
Standalone / Reference Posts
2026.04.07
What Is PostgreSQL? A 10-Minute Beginner Guide
New to databases? This guide explains what PostgreSQL is, why teams pick it for web and analytics workloads, and how tables, rows, and columns fit together—without assuming prior DBA experience. You get a short, readable SELECT example and a clear path to what to study next, so the official docs feel approachable instead of overwhelming.
Read postLatest Updates
Start from the series hub to follow the full flow.
Why PostgreSQL?
Why PostgreSQL? Part 5 — The ecosystem: pgvector, PostGIS, TimescaleDB
One more PostgreSQL extension—and you can seriously discuss vector search, geospatial queries, time-series analytics, and BM25-style full-text search on the same engine. This series finale walks through pgvector, PostGIS, TimescaleDB, and ParadeDB (pg_search): what public benchmarks and vendor write-ups claim, where “replace the specialist” is conditionally true, and how to read latency/cost numbers when managed services, self-hosting, and tuning assumptions differ. It closes the five-part arc on why PostgreSQL is often the lowest-regret default—reliability, extensibility, ecosystem depth—and when a separate system still earns its place. Use the decision inputs at the end alongside the comparison table: growth rate, staffing, failure tolerance, compliance, and how you define TCO.
Recent posts in this topic
Why PostgreSQL?
Why PostgreSQL? Part 4 — MongoDB & Oracle: real migration stories
If you are already on MongoDB or Oracle, moving to PostgreSQL is not a vague someday project—it hits budget, performance, and operations immediately. This post stays between the two lazy extremes (“trivial” vs “impossible”): what triggered real MongoDB→Postgres and Oracle→Postgres moves, how long they took, what hurt more than expected, and what changed afterward. Figures such as Infisical’s reported database cost reduction after leaving MongoDB, or wide TCO improvement narratives away from Oracle, come from public write‑ups, case studies, and vendor materials—so you should separate license vs labor vs migration project costs and read them as directional, not universal guarantees. The article also stresses that schema redesign and query work often travel with the database change, so “Postgres magic” and “refactoring wins” should not be collapsed into one headline. It closes with a compact decision frame so you can judge whether migration is a sensible next step for your team—not a moral obligation.
Why PostgreSQL?
Why PostgreSQL? Part 3 — Startups: the sweet spot of speed and cost
Part 2 explained why large tech companies keep PostgreSQL in the stack; this installment shifts to early product teams where the decision is usually about shipping an MVP quickly, keeping costs predictable, and avoiding a painful rewrite a few quarters later. For web and AI products, PostgreSQL has become the practical default—but much of the perceived ease comes from managed platforms such as Supabase and Neon and from extensions like pgvector, not from pretending the engine alone removes all work. The article separates relational modeling and extensions from provisioning, pricing, and developer experience, and it reads ARR estimates, YC adoption figures, and vector benchmarks as different axes with different definitions. It also stresses workload assumptions behind vendor benchmarks and closes with the operational habits—schema discipline, migration safety, backups—that determine whether the same Postgres choice stays cheap in production.
Why PostgreSQL?
Why PostgreSQL? Part 2 — Why Big Tech Chose PostgreSQL
For years, a common story said you eventually “graduate” from relational databases when you scale. Yet Instagram, Reddit, and Zalando publicly describe a different pattern—scaling PostgreSQL itself, complementing it with Aurora or Kubernetes operators, and using distributed stores where eventual consistency is acceptable. This post treats well-known engineering write-ups as source material, separates throughput, latency, and consistency before comparing headline numbers, distinguishes self-managed PostgreSQL from Aurora-style managed layers, and ties in hidden operational cost and team skill—the full context behind why the same engine keeps appearing next to Cassandra and Kafka. It is written for readers who want defensible framing, not a single-vendor slogan.
Why PostgreSQL?
Why PostgreSQL? Part 1 — Where PostgreSQL Stands in the Numbers
Stack Overflow surveys, enterprise adoption figures, and managed offerings from major clouds—we read where PostgreSQL stands in 2025 with numbers you can cite, not slogans. The goal is to show which signals are trustworthy and where headlines oversimplify the story. This is the first post in a series for practitioners who want evidence when they choose or defend a database.
What Is PostgreSQL? A 10-Minute Beginner Guide
New to databases? This guide explains what PostgreSQL is, why teams pick it for web and analytics workloads, and how tables, rows, and columns fit together—without assuming prior DBA experience. You get a short, readable SELECT example and a clear path to what to study next, so the official docs feel approachable instead of overwhelming.