Tuesday, April 14, 2026
Volume 1.3
All posts
Lv.2 BeginnerPostgreSQL
18 min readLv.2 Beginner
SeriesWhy PostgreSQL? · Part 1/5View series hub

Why PostgreSQL? Part 1 — Where PostgreSQL Stands in the Numbers

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.

Series outline

  • Part 1 — PostgreSQL in the numbers (this post)
  • Part 2 — Why big tech chose PostgreSQL (Instagram, Spotify, Coinbase, …)
  • Part 3 — Startups and PostgreSQL: speed vs. cost
  • Part 4 — Escaping MongoDB/MySQL: real migration stories
  • Part 5 — The ecosystem: pgvector, PostGIS, TimescaleDB

Table of contents

  1. Introduction: why “why PostgreSQL?” still matters
  2. PostgreSQL in the 2025 developer ecosystem
  3. Enterprise adoption across scales
  4. Cloud vendors: everyone is betting on PostgreSQL
  5. Thirty-five years of open source to the top
  6. Closing: beyond the numbers

1. Introduction: why “why PostgreSQL?” still matters

When picking a database, developers used to ask:

“Should I use MySQL or PostgreSQL?”

In 2025, among developers starting new projects, that question is less central than it used to be. In legacy stacks, cost- or ops-constrained setups, or shops tied to a vendor or host, MySQL (or another RDBMS) can still be the obvious choice. Safer than saying the debate “vanished” is to say it has grown less common.

PostgreSQL is no longer just “a strong alternative to MySQL.” It ranks highly on the Stack Overflow Developer Survey, runs in countless production systems, and appears in major clouds as PostgreSQL-compatible or PostgreSQL-based managed services.

So which numbers support that story? Part 1 looks at them head-on. They are not trivia—they set context for later parts on why organizations pick PostgreSQL.

Every table below uses a different population and definition. Do not chain them into a single implied ranking.

2. PostgreSQL in the 2025 developer ecosystem

Stack Overflow Developer Survey (2025)

The annual Stack Overflow Developer Survey is a common reference for tech trends. Respondents are self-selected developers, so this is not a proxy for all IT purchasing—treat it as developer-community signal.

DatabaseUsage (2025)Usage (2024)Usage (2023)
PostgreSQL55.6%48.7%45.6%
MySQL40.5%40.3%41.1%
SQLite37.5%33.1%30.9%
Oracle10.6%10.1%9.8%

Source: Stack Overflow Developer SurveyAll respondents for each year; the question asks who did extensive development with the database in the past year or wants to next year (multiple selections allowed).

The same figures as horizontal bars (not a pie chart—multi-select means the percentages do not sum to 100%):

Stack Overflow 2025 — top four databases by share

Compared with earlier years, PostgreSQL’s share has climbed steadily. The interesting part is not only the level but the pace: about 3.1 percentage points from 2023 to 2024, and about 6.9 points from 2024 to 2025—acceleration is plausible.

DB-Engines ranking

DB-Engines scores “popularity” from search trends, job posts, forum mentions, and more. It is not the same metric as the Stack Overflow percentages above.

As of September 2025, PostgreSQL’s DB-Engines score was 657.17, up 12.81 points year over year. It sits behind Oracle, MySQL, and SQL Server in the overall ranking but is often cited among the fastest-growing at the top tier.

3. Enterprise adoption across scales

Developer preference and enterprise adoption are not identical—yet PostgreSQL scores well on both in many analyses.

Reports that focus on companies with annual revenue above $200M sometimes cite roughly 11.9% running PostgreSQL in production—a signal that serious transactional and mission-critical workloads use it (always check the report’s exact definition and sample).

Some market analyses put PostgreSQL’s share of the overall relational database market at 16.85% in 2025; in open-source RDBMS segments it is often second after MySQL, with PostgreSQL trending up while MySQL is flat or slightly down.

Public examples of PostgreSQL in core infrastructure include:

  • Instagram — data at massive user scale
  • Spotify — streaming and playlists
  • Reddit — community platform OLTP
  • Coinbase — regulated, auditable financial domain
  • Zalando — e-commerce catalog and orders
  • NASA — exploration and analysis data
  • U.S. Department of State — security and stability requirements

These show usage, not “PostgreSQL only.” Large systems usually pair caches, message queues, columnar stores, and more. PostgreSQL is often one relational pillar—not the entire data plane. Parts 2 and 3 go deeper.

4. Cloud vendors: everyone is betting on PostgreSQL

A useful signal is where hyperscalers place their products.

Today, major clouds offer PostgreSQL compatible or derived managed services. Storage engines, HA, and version compatibility differ—treat “PostgreSQL in the name” as a family, not one operational experience. Migration, lock-in, and cost need separate analysis.

CloudExample PostgreSQL-related offeringsNotes
AWSAmazon Aurora PostgreSQL, etc.Mature line
Google CloudAlloyDB, etc.Managed, PostgreSQL-compatible
Microsoft AzureAzure HorizonDB (preview), Azure Database for PostgreSQL, etc.New engine alongside existing managed Postgres—check regions and GA in docs
IBMCloud Databases for PostgreSQL
OraclePostgreSQL-compatible and dual-run strategiesVerify naming per product

Microsoft adding HorizonDB-style offerings widens options; paths from Azure Database for PostgreSQL remain documented separately. For real adoption, weigh SLA, region availability, pricing, and coexistence with MSSQL or Oracle estates.

Supabase hired Vitess co-creator Sugu Sougoumarane and announced Multigres—a sharding/proxy direction for PostgreSQL—on the company blog (early stage; check repos and roadmap). It is one more sign the ecosystem is tackling horizontal scale head-on.

5. Thirty-five years of open source to the top

PostgreSQL traces to the POSTGRES research project at UC Berkeley (1986) led by Michael Stonebraker. Widespread open-source adoption came in the mid-1990s; since then, community and vendors have stacked features together.

As of January 2025, community scale is sometimes summarized roughly as:

  • Core team: 7
  • Committers: 30
  • Major contributors: ~50
  • PostgreSQL 17 contributors (total): 463 (~103 more than the prior year)

What matters is not the headcount alone but that EDB, Google, Microsoft, Amazon, and others invest engineering in the project—somewhere between “weekend hobby” and “single-vendor product,” a globally collaborative engine.

Recent releases

  • PostgreSQL 17 (September 2024): incremental backup on the server side, stronger links between JSON and relational modeling, logical replication improvements, etc.
  • PostgreSQL 18 (around September 2025): use the release notes for authoritative features (e.g. UUID v7, generated columns, storage tuning)—details can shift near release.

A predictable major release each autumn helps enterprises plan upgrades.

6. Closing: beyond the numbers

In short:

  • Strong PostgreSQL showing in the developer survey (55.6% in 2025 for all respondents, under the survey’s definition).
  • DB-Engines and similar composite indices also describe top-tier, rising traction.
  • Market-share reports may cite figures like 16.85%; large-revenue adoption studies exist too.
  • Major clouds ship PostgreSQL-compatible or PostgreSQL-based managed services.

None of this means “PostgreSQL is always the answer”—it shows where gravity is shifting in technology choices.

Part 2 will look at how organizations such as Instagram, Spotify, and Coinbase use PostgreSQL—within what public blogs and posts allow.


Next — Part 2: Why big tech chose PostgreSQL
PostgreSQL alongside caches, queues, and compliance at scale—using public case material.


References


April 2026 — Market-share and adoption figures vary by analyst and definition; always read the original report’s methodology.

Share This Article

Series Navigation

Why PostgreSQL?

1 / 5 · 5

Recommended Reads

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.

Read

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.

Read

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.

Read

Explore this topic·Start with featured series

한국어

Follow new posts via RSS

Until the newsletter opens, RSS is the fastest way to get updates.

Open RSS Guide