Elephant Roads: a tour of Postgres forks

Most users know that PostgreSQL has a 23-year development history. But did you know that Postgres code is used for over a dozen other database systems? Thanks to our liberal licensing, many companies and open source projects over the years have taken the Postgres or PostgreSQL code, changed it, added things to it, and/or merged it into something else. Illustra, Truviso, Aster, Greenplum, and others have seen the value of Postgres not just as a database but as some darned good code they could use. We'll explore the lineage of these forks, and go into the details of some of the more interesting ones.

8.
Illustra: The First Fork
● Stonebraker and a team from UC Berkeley
forked POSTGRES in 1992
● added SQL support
● added new object-relational features
● Started a new company called Miró
● Miró became Montage
● Montage became Illustra

10.
PostgreSQL: The Second Fork
● 1995: a rag-tag band of POSTGRES users and
students decided to save the DBMS by taking it
off-campus.
● It became: Postgres95
● 1996: they put it on a public CVS server
● ported it to SQL
● It became: PostgreSQL
● you know the rest from here ...

11.
Postgres Begat Many More Forks
● Because of the ● Because our code is
license clean and easy to
● Because there's a modify
history of forks ● Because Postgres is
modular and easy to
break up or add to
● Because the
community is OK with
forks and variants

12.
Why Change PostgreSQL?
● To experiment with new DB technology
● To commercialize it
● To bundle it with useful tools
● To specialize it for specific tasks
● To add features the community doesn't want
● or that aren't ready for OSS yet
● Because you can!

14.
Forks Are Good
● Open source means freedom to fork
● If nobody forks a project, then it's not
widely used or actively developed.
● Most forks and their owners
contribute to core PostgreSQL
● money, code, ideas
● Some forks develop code to be
integrated into main Postgres
● best way to try out really challenging
ideas

15.
4 Types of Postgres Variants
● Forks: incompatible or proprietary major
changes to the core code.
● Patches: compatible, open source major
changes to the core code.
● Add-Ons: major middleware or plugins which
greatly enhance or change Postgres's
functionality
● Redistributions: repackaging Postgres under a
different name and/or license