Once upon a time, several years ago, one of our engineers asked us a funny question: “Is our database a bird or a horse?”. This was right before the initial launch of TimescaleDB, and we were trying to find the right name for our new database. He was trying to ask a branding question: is our database light and fast, or is it solid and reliable?
Immediately, “birdhorse” entered the company lexicon as a playful term for something that is a seeming contradiction, a “best-of-both-worlds.”
Our answer? Both. TimescaleDB was a contradiction: a new, innovative, fast-moving database that was also rock solid and reliable.
Right from the start, we saw this contradiction in TimescaleDB usage. One month after we launched (in April 2017), a European utility replaced Redis with TimescaleDB as the database backing their dashboards. Soon after, Cray Supercomputing started deploying TimescaleDB to track power usage in their supercomputers (paper). Later that year, Bloomberg started using TimescaleDB in their ubiquitous terminal application as part of a geo-temporal use case.
Back then—and even now—it surprised us how quickly these seemingly traditional enterprises were adopting a new technology like TimescaleDB. We were also surprised by all the love TimescaleDB received on innovative developer forums like HackerNews. TimescaleDB was a true birdhorse.
Now, after nearly a decade in this business and 25 years of working with databases, I’ve realized that PostgreSQL might be the first true database birdhorse. PostgreSQL is the contradiction, and that is a key reason why it has been so successful.
Thanks to this business, we have gotten a front-row view of PostgreSQL usage. And we’ve noticed a peculiar trend:
The trends in PostgreSQL usage we see here at Timescale
Our data shows that the organizations using PostgreSQL the most are typically either traditional slow-growth enterprises or new, cloud-native innovative startups.
On one side, we see traditional enterprises like Hewlett Packard Enterprise, Schneider Electric, or Warner Music Group moving to PostgreSQL from traditional databases like Oracle and SQL Server. Adopting PostgreSQL as their database has enabled these companies to modernize their stack and their business while easing their organization through a digital transformation.
On the other hand, we also see cloud-native innovative startups like Orbweaver, Indexing Co, or Skylab choosing to build on PostgreSQL from the start so that they can focus on building their application and delighting their users without having to worry about their database.
In this way, PostgreSQL is unique. We can’t think of any other technology that has the same level of enterprise trust and maturity and attracts substantial new developer love. For example, no one graduating from college today is learning IBM DB2.
Stretching Across the Chasm
To understand how truly unique this is, let’s take a look at how markets adopt new technologies.
A new technology will initially appeal to “innovators,” who are motivated by trying new things and are more tolerant of rough edges and instability. Eventually, the technology matures, thanks to a smooth whole product experience and ubiquitous social proof, which de-risks the technology for less adventurous adopters.
However, at this point, the technology has lost its shiny new appeal, and the innovators and early adopters have moved on to the latest, new thing. There is typically a gap or a “chasm,” between the early and later folks.
Yet PostgreSQL defies this rule: it stretches across the chasm, simultaneously appealing to innovators and laggards.
But how?
The PostgreSQL Extension Framework
To start answering this question, we talked to 15 developers who used Postgres across a variety of industries and asked them to describe what Postgres meant to them. What we heard most often was “extensible” or “flexible.” (We also heard words like “beautiful,” “best,” “ubiquitous,” and “everything, everywhere, all at once.” Postgres does get quite a bit of developer love.)
Those responses confirmed our own intuition: that the answer to the Postgres paradox lies in its extension framework.
In 2011, one of the most impactful capabilities was added to PostgreSQL: the power to support extensions, software modules that add functionality to the core database.
Extensions enable developers to add functionality to PostgreSQL independently, quickly, and with minimal coordination. PostGIS adds geospatial capabilities. TimescaleDB adds time-series capabilities. Pgvector adds vector database support.
Thanks to the extension framework, PostgreSQL became a platform: a steady, rock-solid base with fast-moving innovations on top. Core developers could release a steady stream of new versions once a year through a very thorough process. Startups could release new versions much more frequently, even once a month, without needing to coordinate with core.
Identifying the extension framework as the key reason also helped us understand why we saw such little Postgres usage in the upper right box, in the “high growth, high revenue” category. Most of these companies were founded 10-20 years ago: either before or shortly after the extension framework was added to Postgres. These companies made their foundational technology decisions before Postgres became a true birdhorse.
What this means is that, as the current crop of new startups adopt Postgres, in another several years we will start seeing more Postgres usage in the upper right box.
Postgres for Everything
Today the PostgreSQL ecosystem is incredibly rich, with extensions for a variety of use cases:
Today, if you are building a new application or modernizing an existing one, the database choice should be easy: PostgreSQL, for everything. And if anyone asks why, just say, “birdhorse.”
How OpenSauced Is Building a Copilot for Git History With pgvector and Timescale
