Everyone Uses PostgreSQL... But Why?

PostgreSQL is the most-used database among developers, and the gap is widening. In the 2025 Stack Overflow Developer Survey - still the most recent edition, released at the end of 2025 - it was reported by 55.6% of all respondents and 58.2% of professional developers, up from 48.7% in 2024. That roughly seven-point jump is the largest single-year gain in its history, and it pushed the lead over second-place MySQL out to about 15 points overall and 18.6 points among professionals (Stack Overflow 2025). It is also the "most admired" database at 65.5% and the one developers most want to use next, both for several consecutive years. The reasons are not marketing: a permissive license, an extension system that lets the database absorb new workloads, and standards-compliant SQL that ages well.

If that were not signal enough, the money followed in 2025. Databricks acquired the serverless-Postgres startup Neon for roughly $1 billion, and weeks later Snowflake bought Crunchy Data for about $250 million to build "Snowflake Postgres" (The Register). Two of the largest analytics platforms in the world decided that the database they needed for the AI-agent era was Postgres - and notably, Neon reported that over 80% of the databases on its platform were being created by AI agents rather than humans. When agents spin up a database without being told which one to use, they reach for Postgres.

Who actually uses PostgreSQL, and on what

Adoption shows up two ways: developers picking it directly, and cloud vendors building products on it. On DB-Engines, PostgreSQL still sits fourth overall in 2026 behind Oracle, MySQL, and SQL Server, but it has been one of the fastest climbers for years while those three are flat or declining (DB-Engines). DB-Engines weights search and job-listing presence, which favors decades-old incumbents; by the measure that tracks what developers actually build on today, Postgres is already first. Among open-source relational databases it is the clear leader in mindshare.

The cloud side is more telling. Nearly every major provider ships a Postgres product, but they fall into two groups, and the distinction matters when you evaluate compatibility and lock-in.

RDS, Cloud SQL, Azure Database, Neon, Supabase, and the new Snowflake Postgres all run real PostgreSQL, so extensions and edge-case SQL behave as upstream does. Aurora and AlloyDB keep the wire protocol and most SQL but swap the storage engine for distributed, faster-scaling alternatives, which means some extensions and internals differ. CockroachDB speaks the Postgres wire protocol without sharing its code and has measurable feature gaps. The fact that all of these chose Postgres as the thing to be compatible with - and that Databricks and Snowflake paid a combined $1.25 billion to bring it in-house - is itself the adoption signal.

Why developers pick it over Oracle and others

The license is the foundation. PostgreSQL ships under the PostgreSQL License, a permissive BSD/MIT-style license with no per-core fees, no audits, and no restriction on commercial use or redistribution. That is the direct contrast with Oracle and SQL Server, where licensing cost and audit risk are a recurring operational concern. It is also why AWS, Google, Microsoft, Neon, Supabase, and others can build paid products on it without legal friction.

Beyond cost, the engineering substance holds up. PostgreSQL uses MVCC (multi-version concurrency control), so readers do not block writers and writers do not block readers - each transaction sees a consistent snapshot. It tracks the SQL standard closely and supports window functions, common table expressions, recursive queries, and full ACID transactions including transactional DDL, which lets you wrap schema migrations in a single transaction and roll them back cleanly. The index types go well past B-tree: GIN and GiST for composite and full-text data, BRIN for large append-only tables, and HNSW (via pgvector) for vector similarity. Both physical (streaming) and logical replication are built in.

The project also keeps moving. PostgreSQL 18, released in September 2025, added an asynchronous I/O subsystem that has shown up to 3x faster reads from storage, along with B-tree skip scans, timestamp-ordered UUIDv7 generation, virtual generated columns, and built-in OAuth 2.0 authentication. None of these are headline-grabbing features, but together they are the reason a database first released in the 1990s keeps winning new workloads instead of aging out.

The other reason is JSONB. PostgreSQL can store, index, and query inside JSON documents - a GIN index over a JSONB column makes containment lookups and nested-field access fast, so the database acts as a document store when you need it to without giving up relational guarantees. For most applications, that single feature removes the reason many teams reach for a second datastore (see JSON vs JSONB for when to use each).

"Just use Postgres for everything"

The extension system is what turns one database into a platform. Extensions add types, operators, index methods, and even storage hooks without forking the codebase. A few that anchor whole categories of use:

• PostGIS - a full geospatial engine, the de facto standard for spatial queries.
• pgvector - vector storage with IVFFlat and HNSW indexes, covering most retrieval-augmented-generation and semantic-search workloads without a dedicated vector database.
• TimescaleDB - time-series partitioning, compression, and continuous aggregates.
• Built-in full-text search via tsvector/tsquery, and foreign data wrappers that let Postgres query other systems as if they were local tables.

This is the practical core of the "Postgres for everything" trend: vector search, geospatial, time-series, queueing, and document storage can all live in one engine you already operate, instead of five systems you have to integrate, secure, and keep in sync. That consolidation is real, but it has limits, which is the honest part of the story.

The trade-offs nobody mentions in the pitch

PostgreSQL is not free of sharp edges, and most of them surface at scale.

The connection model is the first wall most teams hit. Because every connection is an OS process, a few hundred direct connections consume real memory and scheduler time, so production deployments put a pooler in front - and "too many connections" is one of the most common errors new Postgres operators see. MVCC's cost is bloat: every update writes a new row version and leaves the old one for vacuum to reclaim, and on large tables the default autovacuum thresholds let millions of dead tuples pile up before cleanup starts. There is no native multi-master, so write scaling beyond one primary means sharding (Citus) or a compatible distributed database.

Major upgrades, while well-supported, remain a planned operation rather than a background event - but this is exactly where the gap is closing. PostgreSQL 18's pg_upgrade now preserves planner statistics across the upgrade, so a database reaches full performance immediately instead of limping through a post-upgrade ANALYZE, and new --jobs and --swap options cut the cutover window. The sharp edge is duller than it was a year ago.

None of these are reasons to avoid Postgres. They are the operational surface area you take on, and they are exactly where observability and performance tuning pay off: catching index bloat before vacuum jobs block queries, spotting connection exhaustion before it errors out, and finding the slow queries that quietly dominate latency. This is the kind of database maintenance Pulse automates for the engines it supports today (ClickHouse, OpenSearch, and Elasticsearch), with PostgreSQL support on the roadmap. The point holds regardless of tooling: Postgres rewards teams who watch its internals.

Frequently Asked Questions

Q: Is PostgreSQL really the most popular database now?
A: By developer usage, yes. The 2025 Stack Overflow Developer Survey - still the most recent edition - reported PostgreSQL as the most-used database at 55.6% of all respondents and 58.2% of professionals, roughly 15 points ahead of MySQL. On DB-Engines, which weights search and job-listing presence, PostgreSQL is fourth overall in 2026 but the strongest long-term climber.

Q: Why do people choose PostgreSQL over Oracle?
A: The main drivers are licensing and flexibility. PostgreSQL is free under a permissive BSD/MIT-style license with no per-core fees or audits, while Oracle carries significant licensing cost and audit risk. PostgreSQL also matches the SQL standard closely and offers an extension ecosystem Oracle does not.

Q: Is PostgreSQL free for commercial use?
A: Yes. PostgreSQL is released under the PostgreSQL License, a permissive open-source license that allows commercial use, modification, and redistribution without fees. That is why cloud vendors and startups build paid products on top of it.

Q: What is the difference between Amazon RDS PostgreSQL and Aurora PostgreSQL?
A: RDS for PostgreSQL runs the actual PostgreSQL engine, so behavior and extensions match upstream. Aurora PostgreSQL is PostgreSQL-compatible: it keeps the wire protocol and most SQL but uses a custom distributed storage engine for faster scaling and replication, so some internals and extensions differ.

Q: Can PostgreSQL replace a vector database or a document store?
A: For many workloads, yes. The pgvector extension adds vector similarity search with HNSW indexing, and JSONB with GIN indexes gives document-style storage and querying. Dedicated systems still win at extreme scale, but Postgres removes the need for a separate datastore in most applications.

Q: Why did Databricks and Snowflake buy PostgreSQL companies in 2025?
A: Both are positioning for the AI-agent era. Databricks acquired Neon for roughly $1 billion and Snowflake bought Crunchy Data for about $250 million to launch "Snowflake Postgres." Neon reported that more than 80% of databases on its platform were being created by AI agents rather than humans, and an operational store that agents can spin up on demand needs to be cheap, standard, and serverless - which is exactly what Postgres has become. The acquisitions are a strong signal that Postgres is now the default operational database for new AI-era platforms.

Q: What are the biggest limitations of PostgreSQL?
A: The process-per-connection model needs a connection pooler at scale, MVCC produces table and index bloat that autovacuum must manage, there is no built-in multi-master replication, and major-version upgrades require a planned pg_upgrade. PostgreSQL 18 narrowed that last one by preserving planner statistics across upgrades and speeding up the cutover. These are operational concerns, not correctness problems.

Q: Does PostgreSQL scale to large workloads?
A: A single PostgreSQL primary handles very large read and write volumes with read replicas and partitioning. Scaling writes beyond one primary requires sharding (for example via the Citus extension) or a Postgres-compatible distributed database like YugabyteDB, since core Postgres has a single write primary.

Related Reading

• PostgreSQL Tutorial: a practical getting-started guide to PostgreSQL.
• PostgreSQL vs MySQL: how the two most popular open-source databases compare.
• MongoDB vs PostgreSQL: document store versus relational with JSONB.
• PostgreSQL Vector Search with pgvector: storing and querying embeddings inside Postgres.
• PostgreSQL JSON vs JSONB: when to use each document type.
• PostgreSQL Connection Pooling with PgBouncer: handling the process-per-connection model at scale.
• Managed PostgreSQL Hosting Providers Comparison: comparing the major managed Postgres offerings.
• PostgreSQL 18 Release Notes: async I/O, skip scans, UUIDv7, and easier major-version upgrades.
• PostgreSQL Performance Tuning: finding and fixing slow queries and bloat.