What the PostgreSQL community has done so right

What the PostgreSQL community has done so right

Commentary: PostgreSQL is popular for a variety of reasons, but what has the PostgreSQL community done to ensure this long march to popularity?

datascience

Image: iStock/metamorworks

Must-read developer content

PostgreSQL went years without getting much in the way of accolades, just steadily releasing predictable, stable code. Lately, its popularity has boomed, prompting me to write repeatedly about its success: Amazon just open sourced an easier path to PostgreSQLDevelopers increasingly pair MongoDB with PostgreSQL, survey finds, and Why Oracle’s missteps have led to PostgreSQL’s ‘moment’ in the database market. I thought I was done, and then System Initiative cofounder Adam Jacob started riffing on the reasons behind PostgreSQL’s success, causing me to wonder what makes the community behind PostgreSQL’s rise so different. 

After all, as Jacob pointed out, “Other databases offer better models for a given niche, but nothing so elegantly can be twisted into whatever shape you need it to be.” That may be true, but why is it true? Arguably most databases strive to be malleable to a wide array of use cases. Even things like time series databases that once seemed niche have gone general purpose. So what did the PostgreSQL community get right to allow it to not merely aspire to fit a wide range of use cases, but actually deliver?

SEE: How to launch a successful developer career (TechRepublic Premium)

Better by design

There’s a lot to love about PostgreSQL, including its flexibility. After decades of being put to work, it’s perhaps not surprising that PostgreSQL can be easily adapted, as Jacob called out: “If you want, you can easily make the database feel completely custom to your domain model–the application can be completely abstract from the underlying implementation. Of course, if you don’t like that, you can feel free to just build migrations of the basic schema, and put that SQL directly in your application. Both paths work, both are optimized and understood.” 

Again, all great, but PostgreSQL is not unique in striving for this goal. Rather, it’s somewhat unique in actually achieving it. 

For this, a great deal of credit goes to the person who first created the database: Michael Stonebreaker. As Berkeley computer science professor Joseph Hellerstein wrote about Stonebreaker’s legacy: 

While many things have changed in 25 years, the basic architecture of PostgreSQL remains quite similar to the university releases of Postgres in the early 1990s, and developers familiar with the current PostgreSQL source code would have little trouble wandering through the Postgres3.1 source code (c. 1991). Everything from source code directory structures to process structures to data structures remain remarkably similar. The code from the Berkeley Postgres team had excellent bones.

Crunchydata’s Craig Kerstiens builds on this, arguing that “[A]s a database it took a counterintuitive approach to most. It was never the ‘easy to use’ database, [to be honest] it still isn’t when compared to some others. But it focused on correctness. It has since become [easier] to use, but that dedication for 20 years on correctness matters.” This idea is echoed by Datasette founder Simon Willison: “I really appreciate how high the bar is for released features. When a new feature becomes available in PostgreSQL I know I can trust it straight away, because I know how high their standards are.”

Though the “bones” were initially sound, it has been this commitment to correctness and quality over a long period of time that really marks PostgreSQL. Other open source database communities, including MySQL, argued the CockroachDB folks, haven’t done quite as well as PostgreSQL in this regard (“MySQL had grown organically over time in a somewhat less principled manner than PostgreSQL”). 

PostgreSQL generally isn’t the first with cutting-edge features–that’s not really its purpose. Rather, the PostgreSQL community has, over time, achieved something remarkable precisely by not aspiring to any remarkable, industry-changing functionality: Boredom. Or, rather, as Google’s Kelsey Hightower adroitly expressed it, “Postgres is what happens when tech gets so good, for so long, it becomes boring.” 

Disclosure: I work for AWS, but the views herein are mine and not those of my employer

Also see

Source of Article