With Postgres adoption skyrocketing, not just the number of users of Postgres grows head over heels, but also the number of organizations that want to benefit from that growth increases. We all are (or rather should be) well aware that the growing number of "variations of Postgres"—or perhaps more harshly, "forks of Postgres"—grows quickly as well. Variations that have but a single goal, which is to lock you in the complete offerings of those individual organizations.
The same Postgres everywhere
At EDB, one of the things we have seen from the start is a general focus on diversity. Diversity of deployment, to be precise. Many organizations do not really want to be restricted to one single solution for all. Based on business requirements through the entire IT architecture and through its entire lifecycle, one single way of doing something most probably will turn out to be not a very good idea.
Making a fundamentally strategic choice to adopt open source in general and Postgres specifically has a lot to do with freedom. Not necessarily freedom as "without cost," as we all have learned the lesson of Open Source does not mean gratis. Rather, freedom as in without constraints.
Choosing one of those variations of Postgres does constitute a constraint. As some of the early adopters are now finding out, those initial benefits really do turn into constraints as your project grows and becomes successful.
By running the same Postgres everywhere, from https://www.postgresql.org, you can still do anything you need to do—plus you will not find any of those limiting factors as you grow and scale your open source journey with Postgres.
PostgreSQL Global Development Group
The world loves Postgres; data proves that. The PostgreSQL Global Development Group (PGDG), led by the PostgreSQL Core Team, builds Postgres. A group, in its largest definition, entails tens of thousands of people that, in some shape or form, contribute to the ecosystem that is Postgres.
The PostgreSQL Global Development Group is the community that does everything required to build and maintain Postgres—from feature design, to writing the actual code, testing and packaging it, to where it is there for you to enjoy. It is the ultimate democracy as described by Founding Core Team member Bruce Momjian in his presentation The Democratization of Databases.
Postgres the database
We are talking about Postgres, which is "a database." At least it seems that way at first glance.. However, Postgres is so much more than that. Based on the teachings of the Relational Database Theory, Postgres has evolved along the lines that Mike Stonebraker set out with the extensibility system. Postgres really morphed into this multifaceted data processing platform, capable of handling relational and non-relational workloads in hyper agile environments, delivering extreme high availability. Doing anything seriously and at scale is hard.
The power of tooling
To help make some of these dealings a bit easier, there is a wealth of tooling for Postgres available out there. We have made a list of some of these critical tools for you to look at and to consider in your Postgres journey.
It is an all encompassing selection that includes tools for:
- Backup and Recovery
- Database administration
- Job scheduling
- Geo information
- And more
Success and growth
As previously stated, we all strive to do well in our projects. Growing the application or the service we are building on top of Postgres is somehow always part of that. And chances might just be that it kicks off. There is an increasing number of users working with your application, there are more and more systems that get connected either to supply data or reuse information from your system. Especially these days where everything is always connected, and people can work from anywhere at any time.
This adds a new dimension to the project and raises the stakes; continuity gets more important by the week or by the day. If you are working with Postgres, chances are you might get into situations where questions bubble up faster than you can find the answers, causing things to go wrong.
Dedicated partners for success
To really tackle these scaling issues, you need to have answers quickly, come to solutions sooner, and solve problems swiftly and once and for all. You would need to be part of the Postgres community to get all of this sorted. Or you can team with EDB. We will have your back on this. As part of the PostgreSQL Global Development Group, home to some of the founding leaders of the PostgreSQL Core Team, we employ Core Postgres developers and many Postgres technologists. EDB has contributed to thousands of organizations’ success with Postgres since 2004.
With the acquisition of 2nd Quadrant, we are proud to have more Postgres expertise within our teams than any other Postgres support organization.
You do not have to invest in becoming part of the Postgres community yourself, as we have done this for you and can bring you all those benefits accordingly as your dedicated Postgres partner.
For the win
It is risky business, creating software—things might go wrong, challenges might come up that you had not anticipated. When it comes to Postgres, or anything related to Postgres, we probably have the answers already figured out. If not, we are able to find those answers 24/7 and put ourselves on the clock for that. Even if something breaks—in Postgres or in one of the tools—we are able to fix it for you! How about that? For mitigation of risks? All that is now bundled in EDB's Community 360 plan, simple and convenient.