PostgreSQL Support: Community and Commercial Support Overview

Developing an optimized PostgreSQL support strategy is key for organizations using PostgreSQL in mission critical areas. 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 the community and commercial PostgreSQL support options, detail common problems teams encounter, and discuss why many organizations need additional support for their PostgreSQL deployments.

• Why Do You Need PostgreSQL Support?
• 5 Common PostgreSQL Problem Areas
• PostgreSQL Support Options
• PostgreSQL Community Support
• PostgreSQL Commercial Support
• Final Thoughts

Why Do You Need PostgreSQL Support?

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 PostgreSQL

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

5 Common PostgreSQL Support Needs

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.

1. Migrations

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.

2. Durability / Resiliency

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.

3. Monitoring and Logging

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.

4. Upgrading

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.

5. Security

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 Support Options

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.

PostgreSQL Community Support

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.

PostgreSQL Support Lifecycle

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.

When a PostgreSQL version reaches EOL, they put out one final release, then mark the version end of life.

PostgreSQL Commercial Support

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.

Final Thoughts

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.

Get Support and Services for Your PostgreSQL Databases

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.

Talk to an Expert

Additional Resources

• Blog - What Is PostgreSQL?
• White Paper – 2021 Open Source Database Trend Report
• Support - Open Source Database Support and Services
• Blog - PostgreSQL vs. MySQL: Key Differences and Similarities
• Blog - EnterpriseDB vs. Postgres: Which Is Better?
• Guide - Decision Maker's Guide to Open Source Databases
• Resource Collection – Intro to Open Source Databases