PostgreSQL Isn't Winning Because It's Better

In the early 2000s, MySQL dominated the open-source database landscape not because it was the most capable option, but because it was the easiest path to a working database. One RPM install on RedHat and you were done. The LAMP stack (Linux, Apache, MySQL, PHP) became the foundation for the first wave of web-scale companies: Google, Facebook, WordPress, YouTube, Wikipedia.^[1][2] PostgreSQL was arguably better on technical merits even then. But "better" loses to "already running," and MySQL was already running everywhere.

Now I'm watching the same pattern play out with PostgreSQL. Just faster.

The toolchain decides for you

Consider how a new developer project starts in 2026. A founder uses Lovable or a similar AI-assisted builder because it's the fastest way to ship a working product. Lovable picks Supabase as its default database layer. Supabase runs PostgreSQL. The developer gets PostgreSQL as a byproduct of choosing the fastest path to a live application. They never evaluated MySQL against PostgreSQL. They never weighed the trade-offs between InnoDB and PostgreSQL's MVCC implementation. They took the path of least resistance, and the path led to PostgreSQL.^[3]

Post-hoc rationalisation fills in the rest. They learn PostgreSQL has JSONB for flexible document storage. They discover the extension ecosystem, pgvector for embeddings, PostGIS for geospatial queries, TimescaleDB for time-series data. They convince themselves these features are why they chose it. They didn't. The toolchain chose for them, and the features became the story they told afterwards.

This isn't unique to Lovable. Supabase, Neon, Render, and Railway all default to PostgreSQL.^[4][5][6] The entire next-generation hosting and deployment ecosystem has quietly standardised on PostgreSQL as the database you get without asking. A developer who starts a project on any of these platforms "uses" PostgreSQL in the same way they "use" Linux: it's infrastructure they inherited, not technology they selected.

The numbers reflect defaults, not decisions

The 2024 Stack Overflow Developer Survey reports that 49% of developers use PostgreSQL, up from 33% in 2018.^[7] MySQL historically led with roughly 59% usage in the 2018 survey, but more recent data shows its share declining into the low 40s as PostgreSQL climbs. Newer research suggests PostgreSQL has secured 55 to 65% of net-new open-source relational projects.^[8][9]

The narrative the industry tells itself is that developers evaluated both databases and chose PostgreSQL because it's technically superior. That narrative is misleading. A significant portion of that 49% ended up on PostgreSQL through their toolchain, their hosting provider, or their framework's default configuration, without making a deliberate database decision at all.

This isn't criticism. Taking defaults is rational behaviour. Evaluation is exhausting, and for a startup trying to ship quickly, the database decision is rarely the bottleneck worth optimising. The problem is when the industry mistakes default adoption for deliberate endorsement, because the implications for long-term operations are different in each case.

The LAMP stack precedent

This pattern has played out before, and understanding the precedent helps explain what comes next. MySQL's dominance in the 2000s wasn't driven by technical evaluation either. The LAMP stack was a package deal: Linux was free, Apache was the web server that worked, MySQL was the database that installed in minutes, and PHP was the language with the lowest barrier to entry. Three charts comparing these technologies would have shown Apache dominating Nginx, MySQL dominating PostgreSQL, and PHP dominating Python, but the dominance reflected bundling, not preference.^[1]

WordPress alone accounts for an enormous share of MySQL installations. A WordPress site "uses" MySQL in the same way a Supabase project "uses" PostgreSQL: the database was chosen by the platform, not by the operator. The difference is that in 2006, the platform that chose for you was WordPress. In 2026, the platform that chooses for you is Supabase, Neon, or whatever AI-assisted builder is gaining traction this quarter.

The MySQL-to-PostgreSQL migration trend is real and accelerating. Organisations that outgrow their initial toolchain and actually evaluate their database options are increasingly choosing to migrate.^[10][11] But this validates the point rather than contradicting it: the teams that actively evaluate tend to choose PostgreSQL. The teams that don't evaluate tend to end up on whatever their toolchain provides.

Where defaults become fragile

Defaults are powerful, but they carry hidden costs that surface later. Supabase is free to start, and its developer experience is genuinely excellent. But production use means $25 per month plus usage, and by that point the entire application stack is coupled to Supabase's specific PostgreSQL implementation, their authentication layer, their realtime subscriptions, their storage API. The database decision that was never deliberately made has become a platform dependency that's expensive to reverse.

This pattern, where the initial ease of adoption creates downstream lock-in, is familiar to anyone who has operated databases at scale. Aurora looked like a simple upgrade from RDS MySQL until teams discovered that the 5x performance claim didn't match their workload and that Aurora's proprietary storage layer made migration back to standard MySQL non-trivial. The same dynamic applies to any platform that bundles a database as an implementation detail: the abstraction that made adoption easy is the same abstraction that makes migration hard.

For teams that grow beyond the free tier, the question eventually becomes: "Are we on PostgreSQL because it's the right database for our workload, or are we on PostgreSQL because it was the default in a tool we chose for unrelated reasons?" The answer matters because the tuning and operational requirements of a production PostgreSQL deployment are substantially different from those of a managed hobby project. Vacuum tuning, connection pooling, index management, and query plan analysis all require deliberate attention that default adopters may not have budgeted for.

What this means for database teams

If you're running a database team in 2026, the practical implication of default-driven adoption is that an increasing proportion of the PostgreSQL instances landing in your fleet were never architecturally evaluated. They arrived because a product team used a tool that bundled PostgreSQL, the product grew, and now you're responsible for a production database that was chosen by a framework configuration, not by an engineer who understood the workload requirements.

This isn't a PostgreSQL-specific problem. The same dynamic played out with MySQL in the LAMP era, and it plays out with any technology that benefits from platform bundling. But it does mean that the operational profile of PostgreSQL deployments is shifting. Alongside the carefully architected deployments run by experienced DBREs, there's a growing population of PostgreSQL instances that were never deliberately configured, never tuned beyond defaults, and are running workloads they were never evaluated for.

For observability, this has a specific consequence. A database that was deliberately chosen and architected tends to come with monitoring that reflects the team's understanding of its expected behaviour. A database that arrived as a platform default often has no monitoring beyond what the platform provides, which means the first sign of trouble is frequently a user complaint rather than an alert.

The honest question

None of this is meant as criticism of PostgreSQL, which is a genuinely capable database with an exceptional extension ecosystem and a community governance model that gives it structural advantages over MySQL's Oracle-controlled development.^[12][13] Nor is it criticism of developers who adopt defaults, which is, again, rational behaviour.

The point is simpler than that. The story the industry tells about PostgreSQL's rise ("developers chose the superior technology") obscures the actual mechanism ("toolchains embedded PostgreSQL as the default, and developers adopted the default"). Understanding the real mechanism matters because it changes how you think about what comes next. If PostgreSQL is winning on technical merit, its position is secure. If it's winning on defaults, its position is secure only as long as the toolchains that bundle it continue to dominate. Defaults are powerful, but they're also fragile. The next generation of AI-assisted development tools will make their own default choices, and those choices won't necessarily be the same ones Supabase made.

The honest question, whether you're running PostgreSQL or MySQL or both, is the same: did you choose your database, or did you end up there through your toolchain? And if it's the latter, does your operational investment reflect a deliberate adoption, or are you running production on a decision nobody remembers making?