PostgreSQL vs MySQL: The History and Evolution of the Web's Databases

Two Roads Diverged: How PostgreSQL and MySQL Built the Internet You Know

Look at most websites, apps, or backend systems today, and you’ll likely find one of two names: PostgreSQL or MySQL. Together, they power the vast majority of open-source database workloads on the planet. But they didn’t start as rivals. They began as two very different projects, with different philosophies, in different eras — and their divergence shaped how we think about data storage, reliability, and speed.

The Origin Story: A Tale of Two 90s

MySQL arrived first, in 1995, created by a Swedish company called MySQL AB. Its founders, David Axmark, Allan Larsson, and Michael "Monty" Widenius, weren’t aiming for a fully-featured relational database. They wanted something fast, simple, and reliable — a database that could handle read-heavy web traffic without choking. The "My" in MySQL? That’s Monty’s daughter, My.

PostgreSQL’s roots go deeper. It began as Postgres at UC Berkeley in 1986, a research project led by Professor Michael Stonebraker. Postgres was designed to be an object-relational database — it supported user-defined types, inheritance, and complex queries years before they were common. By 1996, a small group of developers took the Postgres codebase, added SQL support, and renamed it PostgreSQL. The name still carries the "Post" in honor of its academic origins.

At the time, MySQL took off like a rocket because it was dead simple to set up and blisteringly fast for basic queries. PostgreSQL stayed in labs and universities, seen as "too complex" or "too academic" for production use.

The Web Boom: MySQL Grabs the Crown

The late 90s and early 2000s were the Wild West of the Internet. Websites needed databases that wouldn’t fall over under traffic spikes. MySQL delivered. It became the default choice for LAMP stacks (Linux, Apache, MySQL, PHP/Perl/Pyton). Facebook, YouTube, and countless early dot-coms ran on MySQL.

But MySQL’s early speed came at a cost: features. It didn’t support transactions, triggers, or stored procedures until later versions. If you wanted ACID compliance (Atomicity, Consistency, Isolation, Durability), you had to switch to InnoDB storage engine — which wasn’t default initially. For many developers, that was fine. A simple blog or forum didn’t need transaction isolation.

PostgreSQL, meanwhile, was quietly building credibility with database purists. It native supported full ACID transactions, foreign keys, view, triggers, and user-defined functions. Its MVCC (Multi-Version Concurrency Control) was a technical marvel — readers never blocked writers. But it was slower, had a steeper learning curve, and lacked the flashy web-friendly tooling MySQL had.

The Fork That Changed Everything: MySQL Under Oracle

In 2008, Sun Microsystems bought MySQL AB for $1 billion. Two years later, Oracle bought Sun — and suddenly the world's most popular open-source database was owned by the company behind its arch-rival, Oracle Database.

This created a flood of uncertainty. Developers worried Oracle would kill MySQL or restrict its open-source nature. In response, Monty Widenius forked MySQL into MariaDB in 2009, which remains a fully open-source drop-in replacement. MariaDB later became the default DB in many Linux distributions.

The Oracle acquisition also gave PostgreSQL a massive boost. Migrating from MySQL to PostgreSQL became a serious option for companies that wanted a permissive license (PostgreSQL uses the PostgreSQL License, similar to MIT) and a database not owned by a corporate giant. Stack Overflow, Instagram, and Apple all moved major workloads to PostgreSQL during this period.

The Modern Landscape: Different Philosophies for Different Jobs

Today, both databases are mature, production-ready tools, but they excel in different areas.

MySQL (and MariaDB) remains the king of straightforward web applications. Its replication is simpler to set up, it handles read-heavy workloads extremely well, and its ecosystem — from phpMyAdmin to WordPress — is vast. If you’re building a standard CRUD app, MySQL will usually be faster out of the box.

PostgreSQL has grown into the Swiss Army knife of databases. Want to store JSON documents? PostgreSQL can do that natively, with indexing. Need geospatial queries? PostGIS is unmatched. Doing advanced analytics? PostgreSQL supports window functions, CTEs, and full-text search that blow MySQL’s out of the water. It’s also the go-to for financial systems, GIS applications, and any workload where data integrity is non-negotiable.

The performance gap has narrowed dramatically. PostgreSQL’s read speed is competitive, and MySQL’s newer versions support JSON, CTEs, and better indexing. But the philosophical difference remains: MySQL optimized for ease and speed; PostgreSQL optimized for correctness and extensibility.

The Cloud Era: Both Are Here to Stay

Cloud providers — AWS (RDS, Aurora), Google Cloud (Cloud SQL), Azure — now offer both databases as managed services. This removes the operational complexity that once separated them. Companies often run both: MySQL for user-facing apps, PostgreSQL for analytics and critical transactions.

A 2023 Stack Overflow survey showed PostgreSQL passing MySQL in developer popularity for the first time. But "popularity" doesn’t mean "dominance" — MySQL still powers millions of tiny sites, legacy apps, and WordPress installations.

The Takeaway for Developers

Don’t choose based on hype. Ask these questions:

• Do you need strict data integrity? Go PostgreSQL.
• Do you need to shard across dozens of servers easily? MySQL has more mature sharding tools.
• Do you need complex reporting or geospatial features? PostgreSQL wins hands-down.
• Are you building a simple blog or e-commerce site? MySQL is faster to deploy and you’ll rarely hit its limits.

Both databases shaped the modern Internet — one by making databases fast and friendly, the other by making them trustworthy and powerful. They’re not enemies. They’re two sides of the same coin, each solving problems the other can’t.