PostgreSQL has acquired a peculiar advantage: databases competing for the same developers deliberately try to look like it, because imitating part of Postgres can be cheaper than building a new ecosystem from zero.
CockroachDB speaks the PostgreSQL wire protocol, cloud services advertise Postgres compatibility, and drivers or ORMs written years ago for PostgreSQL can end up talking to a completely different engine.37 Other products, in other words, have a reason to keep PostgreSQL conventions alive even when PostgreSQL itself is nowhere in the stack.
Michael Stonebraker, who began POSTGRES at Berkeley, offered a more mischievous explanation for the project's rise in an interview with The Register on August 19, 2026. In his telling, Oracle helped by keeping MySQL after it bought Sun, which gave users looking for an independent alternative another reason to consider PostgreSQL.9 It is an interesting witness account, although four decades of database adoption are obviously messier than one decision by Oracle.
The easier claim to test is sitting in front of us: PostgreSQL has become more than a server, because it is also a language that other servers find useful to speak and an ecosystem they can partly inherit.
The wrong winner
The funny part is that POSTGRES, the ancestor of the thing everyone now expects to understand SQL, did not begin as an SQL project at all.
Berkeley started implementing it in 1986, with extensibility near the centre of the design. The team wanted people to add types, functions, operators and access methods rather than wait for the database authors to anticipate every future kind of data.12 Joseph Hellerstein, who worked on the project, later described that extensibility as one of its signature ideas; geometry for CAD, user-defined functions and new indexing methods were exactly the sort of things the design was trying to accommodate.2
When Berkeley stopped the research project at version 4.2, Andrew Yu and Jolly Chen kept going, added an SQL interpreter in 1994 and released Postgres95; the PostgreSQL name followed in 1996.1
So the project that had spent years inventing unusual database machinery made a very practical concession at its boundary: users could talk to it in a language they already knew. The weirdness stayed inside the engine, where it was useful.
Speaking SQL
“Postgres compatible” still needs an asterisk the size of a small migration plan.
SQL is only the first layer, because two systems may both accept SELECT, JOIN and INSERT yet disagree on a type, a lock, a function or the exact behaviour of a transaction once a real application wanders outside textbook SQL.
Underneath the query sits another layer: PostgreSQL documents the protocol used between clients and the server, and PostgreSQL 18 describes protocol version 3.2 while remaining compatible with version 3.0, used since PostgreSQL 7.4.3 The familiar port 5432 is attached to that long-lived agreement about how a client starts a session, sends work and receives results, which is far more consequential than the boring number suggests.
A shared dialect helps a developer recognise the code and a shared protocol may let an existing driver connect, while actual server behaviour decides whether the application survives once the easy part is over.
Wire 5432
Open CockroachDB's compatibility documentation and the commercial value of that old protocol becomes very concrete: CockroachDB supports the PostgreSQL wire protocol and most PostgreSQL syntax, so many Postgres drivers, ORMs and tools work with it.7
Imagine doing the opposite. You have just built a new database engine and now need to persuade people to try it, but first you must ship good Python and Go drivers, JDBC support, adapters for popular ORMs, migration tooling, admin integrations and enough documentation that a developer can get through a Tuesday afternoon without learning your private protocol. The engine was only mountain one.
Speaking Postgres removes a large chunk of that second mountain before the first developer even connects.
The Register also points to YugabyteDB and Timescale when describing the wider PostgreSQL ecosystem.8 The exact family tree is debatable, and the products work very differently, but the incentive is easy to understand. Compatibility lets a newcomer borrow habits and tooling that already exist.
That choice feeds back into PostgreSQL: a library has more reasons to maintain its Postgres path when several products can use it, developers encounter the same conventions in more places, and a later database has an even stronger reason to support them. No ceremony is required to declare a standard when enough people quietly decide that inventing another interface sounds exhausting.
Compatible, not identical
There is a catch, and CockroachDB documents it quite openly: its compatibility page lists unsupported features and differences in behaviour, because a distributed system has constraints that make some PostgreSQL semantics difficult to reproduce.7 The wire protocol can get a client through the front door, while the rooms beyond may still be arranged differently.
For a plain application, reusing a PostgreSQL driver can work nicely; depend on a particular extension, system function, lock, type or transaction detail, however, and the gap can appear fast. “Compatible” is useful shorthand for getting started, rather than a promise that two engines are interchangeable.
PostgreSQL's old taste for extensibility makes this even more interesting. Modern PostgreSQL can be extended with functions, aggregates, types, operators, operator classes and packaged extensions, continuing an idea that was already visible in Berkeley's work.2 Two servers can therefore speak the same protocol while one of them has been turned into a rather specialised machine by everything installed behind it.
Nobody owns it
Technical compatibility is only half the bet, because a company also has to decide whether the interface still looks safe to build around five years from now.
PostgreSQL uses a permissive licence, similar in spirit to BSD or MIT, allowing use, modification and distribution in commercial products under light conditions.4 It also has a real governance structure without a single corporate owner: Core Team, committers, infrastructure and security teams, plus several committees.5 The official FAQ puts it plainly: PostgreSQL is a community project and no company controls it.6
Companies are hardly absent: they employ contributors, sell services and have interests, and community governance certainly does not make disagreements evaporate. What disappears is one particular worry for a company choosing the Postgres interface, because no proprietor can wake up and make the project's public boundary serve a new quarterly plan.
Stonebraker described Postgres to The Register as software that, commercially speaking, “doesn't belong to anybody,” recalling the unaffiliated programmers who carried it after Berkeley.8 Today's governance is more organised than that sentence suggests, but the lack of a single owner is still part of what makes the interface attractive to outsiders.
The invisible product
PostgreSQL has a long feature list, from JSON and replication to indexes, extensions and performance work, and those are the visible parts that a release note can point at.
The quieter asset sits around the server: familiar SQL, a documented protocol, drivers everywhere, permissive licensing and a governance model that does not belong to one vendor. A third party can reuse all of that without asking PostgreSQL for a partnership agreement.
The value appears indirectly when a new engine chooses pgwire because developers already have clients for it, when an admin tool happens to work somewhere its authors never originally targeted, or when a team can test a different backend before rewriting every line that talks to the database.
This is useful beyond database software. Open-source projects spend a lot of energy making the thing in the middle better, while the interfaces around it can become an asset of their own. Keep those interfaces useful, boring and trustworthy for long enough and something slightly absurd happens: even a competitor may decide that your language is the cheapest one to speak.