The PostgreSQL renaissance is several years old now, something I’ve written about repeatedly. The reasons for its popularity? There are several, as consultant Tanel Poder neatly summarizes:

1. Rich set of features2. Extremely extensible (extensions, hooks)3. Open source4. ‘Permissive’ open source license

The thing is, these have been true for some time, and long before PostgreSQL really started to climb the popularity rankings (perhaps bestcharted by OnGres founder Álvaro Hernández, who used linear scale to show the relative growth of PostgreSQL versus the relational database incumbents):

Alvaro Hernandez

MySQL was early to the open source relational database party but was used more to build the nascent web than to displace mainstream enterprise databases. MySQL also ended up owned by Oracle, which hasn’t seemed to slow its development but may have diminished community fervor. Hence, over time MySQL has joined proprietary peers Oracle and SQL Server in declining in popularity relative to not only PostgreSQL, but also to a rising class of NoSQL databases such as Amazon DynamoDB, MongoDB, Redis, Apache Cassandra, and more.

favors general-purpose databases. This isn’t exactly news. What is news is the rush to modernize—and PostgreSQL’s role in it.

Pushing the easy button

Without deprecating (even a little bit) all the various reasons to like PostgreSQL, there’s perhaps one that seems to stand out: It’s easy. It’s not necessarily easier to learn or use than other relational databases. (It’s not even the database newbies trained on MySQL aremost likely to move to.) But for those who are already used to relational databases and want to ditch expensive Oracle, for example, PostgreSQL is the “easy button.” Most companies aren’t looking to lift and shift, as EDB CEO Ed Boyajian once told me, but they are turning to PostgreSQL for their greenfield applications because they already have SQL/relational skills in-house, built up over decades of using Oracle, SQL Server, and DB2.

So even if another database model might actually be better for their use case, the “easy button” is to go PostgreSQL. As ex-AWS engineer Dave Cuthbert notes, “Far more apps are using relational [databases] because it was the only hammer they had.”

Of course, for many enterprise workloads, the people doing the architectures actually aren’t employed by the enterprise but get engaged as consultants. Within the largest global system integrators, there’s that built-in relational experience and, from my conversations with folks in the industry, this tends to be their primary reason for pushing PostgreSQL.

During and after the pandemic, there has been huge demand to modernize enterprise infrastructure to make enterprises more agile and responsive to rapidly evolving customer requirements. Those global system integrators take the modernization projects and often apply the technologies that are easiest for them to deploy, netting them the best margins on their services. We can argue about whether this is actually the best thing for customers wanting to modernize, but it’s not hard to understand the underlying logic.

Now, if you’re me, working for a document database company, it’s fair to think this apparent overreliance on relational is more due to inertia than a concerted attempt to embrace modern data infrastructure. In my view, the “why now?” question is answered by many with “because it’s easy.” Not because it’s best.

“Best” is, of course, subjective, and “because it’s easy” has been a prime driver of everything from open source to cloud. Ease—or convenience—is one heck of a drug. Companies that want to compete with PostgreSQL’s “easy button” need to come up with something at least as compelling. Meanwhile, PostgreSQL doesn’t seem to be eating into NoSQL, but it sure seems to be growing at the expense of the relational incumbents.