Software relies on other software. Apps rely on OS distros—multiple interconnected parts, coming together to make an integrated software stack.
Each of the parts of the software stack is changing and growing, as people strive to add value.
Typically, we want both agility and stability. We want change in the areas *we* care about—ideally rapid, agile change. Yet, we want stability from all the other software.
That leads to conflicts because the changes we want to see aren’t the same as the changes other people care about. And it also leads to difficulties as we seek to provide added value in both agility and stability for our users.
- Stable: sane and sensible, not likely to change or fail, not deteriorating in health
- Agile: able to move and change quickly and easily
PostgreSQL and Stability
PostgreSQL provides stability in a number of ways:
The SQL language is an international standard, published and maintained by ISO. It has evolved slowly over the years, so is still easily used by anyone that learned SQL in the 1970s or 1980s. Some people have sneered at that stability, but it’s now clear that most products now agree that SQL is a useful language and that it makes sense to keep things stable for the millions of developers that know the SQL language. PostgreSQL respects that and maintains close adherence to the SQL specification.
PostgreSQL also provides stability by maintaining software for 5 years per each release, with vendors like EDB providing even longer maintenance periods. Security fixes are published regularly, but overall, once a major release is published, it is kept as close to unchanged as possible over that period. So people can rely on a single released version of PostgreSQL and know that it won’t change under them.
PostgreSQL and Agility
PostgreSQL also provides agility in a number of ways:
The project continues to push forwards on new developments with each new major release, resolving internal architectural flaws and slowly adding new and useful features. EDB is one of the main contributors, amongst a wide range of companies making major contributions. PostgreSQL set new ground in the database industry by publishing and keeping to an annual release policy, where previous database software was released every 3-4 years.
PostgreSQL also pioneered a new form of agility via user-defined additional code modules, known as Extensions. PostgreSQL invented user-defined functions and datatypes in the late 1980s, which was originally commercialized into the concept of a “DataBlade” (in the Illustra database). PostgreSQL code now exposes a wide range of “hooks” that can be used to extend the functionality of the core DBMS. All of these types of code additions can be packaged together into an Extension module that can be easily installed into a database, all based around the now mature technology for dynamic loading of libraries.
The Extension is PostgreSQL’s secret weapon: a mechanism by which software authors can extend the functionality of the database itself in different directions, adding value in new ways, at a software development pace even faster than the annual release cycle. Extensions allow new types of index, empower the world’s most popular GIS database PostGIS and also allow the advanced BDR clustering and replication system.
PostgreSQL provides a number of trusted extensions that are inspected by the PostgreSQL security team. That is not to say that other extensions need cause issues—vendors such as EDB or AWS publish a wide variety of extensions for use by their customers, developed by both open source and commercial software developers.
Building on PostgreSQL
PostgreSQL extensibility is increasing release by release as new architectural capabilities are exposed for independent software authors to utilize. PostgreSQL’s stability makes it the perfect database distro on which to build agile applications.
Want to learn more? Check out our eBook, 5 Ways to Get More from PostgreSQL.