For organizations considering or currently using PostgreSQL, developing an optimized PostgreSQL support strategy is key. Luckily, PostgreSQL is a well-supported ORDBMS, with an active developer community and a variety of paid support options.
In this blog, we give an overview of why companies need an optimized support strategy for PostgreSQL, detail common problems teams encounter, and discuss the community and paid support options available today.
Integrating and maintaining an open source database like PostgreSQL requires both expertise and time. If something goes wrong with critical data in a PostgreSQL database, enterprise companies need to know they have the requisite expertise and time available to mitigate or resolve the issue.
While keeping a PostgreSQL expert on staff can help to accomplish this, that approach is not cost effective at most companies. This self-support approach can mean your developers are spending their time finding and fixing issues instead of actively working toward business goals.
That’s not to mention that even with a community support model as developed and active as PostgreSQL, there are still times when waiting on someone (who isn’t beholden to an SLA) to answer a question in an email thread just won’t cut it.
Lastly, security should be a major priority for any database. Having dedicated support can make the upgrade and patching process much simpler for enterprise organizations.
Get Expert Support for PostgreSQLOpenLogic provides 24/7/365, SLA-backed support for PostgreSQL and other open source databases. Talk to an expert today to see how we can help you with database support.Talk to an Expert
OpenLogic provides 24/7/365, SLA-backed support for PostgreSQL and other open source databases. Talk to an expert today to see how we can help you with database support.
Talk to an Expert
PostgreSQL is generally an easy database to work with. However, there are a number of common and tricky issues that can bog down the best teams.
One of the first problems teams experience when working with PostgreSQL is in migrating to the database from another, often commercial, database. While PostgreSQL does use ANSI standard SQL syntax, there are still subtle differences (e.g. data mapping) that teams must account for.
Another sticking point in migrations is in finding the right plugins/extensions. Most organizations that move to PostgreSQL do so alongside new monitoring and logging technologies, which means those migrating need to account for additional time in integrating supporting technologies.
For organizations using PostgreSQL for critical data, ensuring that data can survive unexpected and catastrophic failures, corruption, inconsistencies, and deletions is essential.
While PostgreSQL does have a durability-minded synchronous replication, that approach can lead to increased response times, and a potential for data loss.
Moving your data to PostgreSQL will likely mean a reconfiguration of your monitoring and logging endpoints and thresholds. For many, it may mean a change in your monitoring and logging technologies.
PostgreSQL also has some unique issues that can trip up teams configuring their monitoring and logging. One example is the limited amount of transaction id’s, which, if not vacuumed correctly, can lead to transaction ID wrap-around.
Considering how many transactions are occurring for most applications, it’s imperative to account for that load and vacuum accordingly.
PostgreSQL recommends upgrading the latest minor version whenever it is released, meaning teams should be ready to perform PostgreSQL version upgrades at least once every three months. These releases are specifically focused on patching bugs, security issues, and data correction issues. For these minor releases, the PostgreSQL community “considers not upgrading to be riskier than upgrading.”
Even if they're not considered risky by the community, both minor and major upgrades can easily trip teams up. For example, missing a schema change in a minor update can cause major issues. This means that teams performing their own upgrades need to religiously follow the migration documentation when performing major and minor PostgreSQL upgrades.
Then, at least once every five years, teams should upgrade to the latest major version to ensure they’re on a community-supported version.
When it comes to database security, IT teams always need to know they’re following known security best practices. Whether that means ensuring data is encrypted, or properly configuring networks to limit exposure, security should be a key consideration for enterprise companies working with PostgreSQL. The minor version releases mentioned above typically include patches for known CVEs, which means upgrading to the latest minor version should be a priority.
Teams also need to remember that these patches typically stop when the major version reaches community support EOL , meaning they need to account for upgrades as part of their long-term security strategy.
PostgreSQL, as an open source RDBMS, offers community support for major releases. But, for enterprise organizations, that community support often does not meet internal or external security requirements. To bolster that support, and to meet these security requirements, many organizations turn to commercial PostgreSQL support.
In the sections below, we give an overview of PostgreSQL community and commercial support options.
The primary means of community support for PostgreSQL is through mailing lists. The mailing list pgsql-general, for instance, is the primary discussion hub for general PostgreSQL questions and problems. The mailing list threads are automatically archived to the PostgreSQL website, where they can be accessed by the public.
The primary complaint among users of PostgreSQL support is that the community format has fallen behind similar databases, and lacks a forward-facing bug repository.
The PostgreSQL support lifecycle follows a 5-year cadence for major versions, with each major version being supported for the five years following the release.
Below, you can see the release date and accompanying end of life dates for currently supported PostgreSQL versions.
End of Life
October 3, 2019
November 14, 2024
October 18, 2018
November 9, 2023
October 5, 2017
November 10, 2022
September 29, 2016
November 11, 2021
January 7, 2016
February 11, 2021
When a PostgreSQL version reaches EOL, they put out one final release, then mark the version end of life.
There are many different options for PostgreSQL commercial support, all ranging in scope, price, and quality. The PostgreSQL website provides a full list of commercial support vendors, though the entries are open to anybody who submits an entry.
PostgreSQL is a great option for anybody who wants a viable RDBMS. It’s been around for 20+ years, has a well-established community, is highly extensible, and has leagues of developers experienced in implementing it.
That said, the increasing demand for strictly enforced security and support requirements, developing and maintaining an optimized PostgreSQL support strategy is key to protecting critical data.
With a wide array of support options available, enterprise organizations should have no problem finding a dependable commercial support vendor.
Need support for your PostgreSQL integration, migration, or configuration? Our team of open source database experts can help to ensure your PostgreSQL implementation is both secure and performant.
Talk to an expert today to see how we can help support your integrated open source.
Enterprise Solutions Architect, OpenLogic by Perforce
Vince has worked in the IT industry for 27 years, as a C developer, a systems administrator, a DBA, and a network engineer. He focuses on infrastructure architecture and open source server technologies, ranging from web servers to authorization technologies like LDAP.
Enterprise Architect, OpenLogic by Perforce
Bill has over 25 years of experience working in various software roles related to full stack development including user interface, middleware, databases (RDBMS and NoSQL), security, DevOps, training, and mentorship. His primary focus is applying open source in the enterprise.