Why Postgres became the default database, and is it really faster?

Engineers say Postgres is the default database so often that leaders start to treat it as settled. A common version of the claim goes further: Postgres is simply faster than the other major SQL engines. That version is not true, and building a decision on it would be a mistake. The true story is more useful, because it tells you what you gain by choosing Postgres and what you take on.

Is Postgres faster than MySQL, SQL Server and Oracle?

No single SQL engine is fastest. Speed depends on the workload, the design of the tables and indexes, the hardware and the tuning, and each of the major engines can win on a specific job. Postgres is fast enough for most business applications and has strengths that matter more than raw speed.

Published benchmarks do not settle it either. The TPC benchmarks each simulate a defined workload, such as TPC-C's order-entry environment, and a result applies to that workload on that configuration. The PostgreSQL project's own benchmarking tool carries a warning in its documentation: "It is very easy to use pgbench to produce completely meaningless numbers." It adds that results are sensitive to how long it has been since tables were initialized, and that autovacuum can change measured performance unpredictably.

The honest claim is narrower: Postgres is a strong, well-rounded engine for transactional business applications, and it is a safe default. Where a workload is unusual, or a company already runs SQL Server or Oracle with deep in-house skill, another engine can be the better call. Uber's 2016 move away from Postgres, covered below, is the best-known published example.

Where did Postgres come from?

Postgres began as a research project. The PostgreSQL history page says implementation of POSTGRES began in 1986 at the University of California, Berkeley, led by Professor Michael Stonebraker and sponsored by agencies including DARPA and the National Science Foundation. It reports a first demo system in 1987, Version 1 released to a few external users in June 1989, Version 2 in June 1990 and Version 3 in 1991. The Berkeley project officially ended with Version 4.2.

In 1994, Andrew Yu and Jolly Chen added an SQL language interpreter, and the result was released to the web as Postgres95. By 1996 the project concluded that the name would not last, chose PostgreSQL, and set version numbering to start at 6.0 to continue the Berkeley sequence. The project's own site now cites nearly 40 years of active development on the core platform and says PostgreSQL has been ACID-compliant since 2001, meaning groups of changes commit together or not at all.

That history explains the culture. The code has had decades of public development, which is part of why teams trust it with records they cannot afford to lose.

Why is Postgres so popular?

Popularity is the best evidence for the "default" claim. In the 2026 Stack Overflow Developer Survey, PostgreSQL ranked first among databases at 57.9% of respondents (6,984 responses), ahead of SQLite at 42.1%, MySQL at 35.1% and Microsoft SQL Server at 27.1%. Oracle was at 9.4%.

That number measures developer use, not speed. It shows that tooling, hosting options, training material and hiring pools are deepest for Postgres. For a 20 to 200 person company that is a practical advantage: the people you can hire, the cloud services you can buy and the vendors you work with all know it.

What actually makes Postgres strong?

Several design choices explain the reputation. Each one comes with a plain-language meaning for a business.

MVCC (multiversion concurrency control) gives each SQL statement a snapshot of the data. The PostgreSQL documentation says locks acquired for reading do not conflict with locks acquired for writing, so reading never blocks writing and writing never blocks reading.

The query planner examines the possible ways to run a query and, per the planner documentation, selects the plan expected to run fastest. For queries with many joins it switches to a genetic query optimizer above a configurable threshold.

Parallel query lets one query use multiple CPUs. The documentation says many queries can run more than twice as fast and some four times faster. The biggest gains go to queries that touch a lot of data but return few rows. It also cautions that many queries cannot benefit.

Postgres offers several index types. The index documentation lists B-tree for equality and range queries, GIN for values with multiple components such as arrays, GiST as a framework for many indexing strategies, and BRIN, which stores summaries about consecutive block ranges of a table. Choosing the right index type is often where large speedups come from.

Extensions add data types, functions, operators and index methods. Two matter most for new projects. The jsonb type, which the PostgreSQL 18 documentation says most applications should prefer for JSON data, supports indexing. And the pgvector extension adds vector similarity search, which AI document search relies on. Our guide to the types of databases shows how far these can replace separate systems.

What is new in recent PostgreSQL releases?

PostgreSQL 18 was released on September 25, 2025. Its release notes list an asynchronous I/O subsystem that can improve performance of sequential scans, bitmap heap scans, vacuums and other operations, plus skip scan lookups that let multicolumn B-tree indexes serve more queries. They also describe faster hash joins and GROUP BY, better locking performance for queries that touch many relations, and a pg_upgrade that now retains optimizer statistics.

The versioning page lists 18 as the latest generally available major version as of October 2026, and 18.6 as the current minor release. It also announces PostgreSQL 19 release candidate 1 on October 15, 2026. The draft version 19 release notes mention a new REPACK command, parallel autovacuum of table indexes and a change to disable JIT compilation by default. Treat those as drafts until the final release.

Release notes show steady engineering work. They do not show that Postgres beats a rival engine on your workload. Only a test with your data does.

What are the real weak spots of Postgres?

Three weaknesses come up repeatedly, and a buyer should know all three.

Connections need a pooler

Postgres uses a process-per-connection model. The documentation says every client process connects to exactly one backend process, and a supervisor spawns a new backend each time a connection is requested. The default max_connections is typically 100. Applications with many instances or short-lived workers can exhaust connections quickly. The usual fix is a connection pooler such as PgBouncer, a lightweight connection pooler for PostgreSQL that sits between the application and the database. Plan for one early if you run serverless or autoscaling services.

Vacuum and bloat need attention

Because of MVCC, an UPDATE or DELETE does not immediately remove the old row version. The routine vacuuming documentation explains that VACUUM reclaims that space for reuse, and that standard vacuum does not return space to the operating system except when pages at the end of a table become entirely free. The same page describes transaction ID wraparound, where a cluster running past about 4 billion transactions without vacuuming could suffer catastrophic data loss. Autovacuum handles this by default, and large, busy tables are where it can fall behind. Notion's October 2021 engineering post says the Postgres VACUUM process began to stall consistently, and called transaction ID wraparound an existential risk. That was a reason it sharded its database.

Updates can amplify writes

In 2016, Uber Engineering explained why it moved from Postgres to MySQL. The post says updating a field in Postgres means every index on the table gets a new entry, even indexes on unchanged fields, and that the physical replication stream became very verbose. It also cited difficulty upgrading between releases and poor support for large connection counts. Postgres skips the index work for heap-only tuple (HOT) updates, when no indexed column changes and the new row version fits on the same page, so the cost falls on tables whose indexed columns change often. The analysis was based on the Postgres 9.2 series, so it describes that era and that workload, not today's versions. It remains a useful reminder that update-heavy tables with many indexes behave differently across engines.

When might another engine be the better choice?

Choose another engine for a reason you can name:

• You already run SQL Server or Oracle with mature tooling, licensed support and staff who know it, and the application depends on its specific features.
• A vendor product requires it. Many packaged ERP and industry systems certify a particular database.
• Your workload matches another engine's design, as Uber's did, and a proof of concept shows a measurable difference.
• Your team has deep MySQL skill and the application is a conventional web workload.

Illustrative example: A 120-person manufacturer is building a supplier portal. One proposal says "use Postgres because it is the fastest." The right response is to ask what the portal does. It stores purchase orders, supplier records and approvals, which are moderate-volume transactional data, and the company's IT team already runs managed Postgres on AWS. Postgres fits for those reasons. The same company's core ERP runs on SQL Server, which the vendor certifies, so it stays there. Two engines coexist, and each choice has a stated reason that has nothing to do with a speed claim.

How Kastling approaches database decisions

Database choice sits within AI & Cloud Infrastructure: cloud architecture and deployment on AWS or Azure, AI application deployment, and the data connections and pipelines behind them. Kastling would start from the workload and the systems already in place, then recommend an engine with the reasons stated, and test critical queries on realistic data before committing. Moving an existing database would begin with a scoped assessment of what depends on it, and success measures would be agreed first. For the wider decision, see our guide to SQL vs NoSQL.