PostgreSQL is developed by a community rather than a company, so there is no vendor to call, and commercial support is sold by a separate market of companies that employ contributors, package their own distributions, or run the database for you. A support contract buys expertise and a response time. It does not run your database at 3am, and the teams that need that are usually better served by a managed instance than by a contract.
The official project maintains a list of professional service companies and declines to recommend any of them, which is the correct thing for a community project to do and unhelpful if you are trying to decide. What follows is how the market is shaped, what the contracts actually contain, and how to tell which of the three kinds of support you need.
Table of contents
- Why Postgres support is a market at all
- The three shapes of support
- What a support contract actually covers
- Who actually needs a contract
- Questions to ask a vendor
- The managed alternative for most teams
- How this fits the rest of the stack
- FAQ
Why Postgres support is a market at all
A commercial database comes with a vendor, and the vendor comes with a support organisation, a licence, and a phone number. Postgres comes with a licence that permits anything, including commercial use, and a community that answers questions on mailing lists when it has time. There is nobody whose job it is to pick up when your primary stops accepting writes.
That gap is filled by companies. Some employ core contributors and sell their time. Some package Postgres with their own tooling for high availability, backups or migration and support the package. Some run it as a service and support that. The official project keeps a directory of them and, deliberately, does not rank it.
This is a feature rather than a defect. It means support is competitive and you can change provider without changing database, which is not true of the commercial alternatives. It also means the buying decision is yours to make with no default.
The three shapes of support
- Community support. Documentation that is genuinely excellent, mailing lists, a wiki, chat channels, and the accumulated answers of thirty years. Free, deep, and on nobody’s schedule. Good for learning and for non-urgent questions; not something to rely on during an outage.
- Commercial support subscriptions. A contract with a company: response-time commitments by severity, a ticket system, named engineers who know your environment, and usually help with upgrade planning, performance tuning and incident review. Priced per instance, per core or per year, and the price scales with the response time you want.
- Managed service. The provider runs the database and support is part of the product. You are not calling about your server; you are calling about their service, and the incidents that a contract would help you through are the ones the provider is handling before you notice.
Most of the confusion in the search results comes from vendors that sell both the second and the third, and from buyers who want the third and are quoted the second.
What a support contract actually covers
Read one and the shape is consistent. Severity levels, from a down production database at the top to a how-do-I question at the bottom, each with a committed response time. Access to engineers by ticket, and at higher tiers by phone. Guidance on upgrades, on configuration, on why a query got slow after a data growth. Review of your architecture before a big change. Sometimes a distribution of Postgres with patches backported to older versions the community no longer maintains.
What it does not cover is worth stating plainly. The contract does not run your database. When the disk fills at 3am, the vendor will help your engineer diagnose it once your engineer is awake and has opened a ticket. The backups are still yours to take. The failover is still yours to configure and test. A contract adds an expert to your team; it does not remove the team.
That is exactly what a large self-hosted deployment wants: their own people, with a phone number for the hard cases. It is the wrong shape for a team that does not have their own database people at all.
Who actually needs a contract
The honest list is shorter than the market suggests.
- Self-hosted Postgres at a size where an outage costs more per hour than the contract costs per year. Terabytes, hundreds of connections, a replica topology someone built and now maintains.
- Regulated environments where a support agreement with response commitments is a compliance requirement, regardless of whether it is ever used.
- Unusual configurations: custom extensions, exotic replication, a version held back for an application that cannot be upgraded.
- Teams with a database administrator who wants backup for the incidents they have not seen before.
Not on the list: a small or medium application with one production database and a team of developers who are not database specialists. For that team the contract solves the wrong problem. Their risk is not an incident they cannot diagnose; it is the backup that was never tested and the patch that was never applied, and a contract does not fix either.
Questions to ask a vendor
- What is the response time for a down production database, and is it measured to first human response or to resolution?
- Are the engineers Postgres contributors, or a support desk that escalates to them?
- Does the contract cover community Postgres, or only your distribution? Switching distributions to get support is a migration.
- What happens at end of life for the major version I am on?
- Is there a minimum term, and is the price per instance, per core or per environment?
- Will you review a backup and restore procedure, or only respond when it fails?
The sixth question sorts vendors quickly. The ones who say yes are selling expertise; the ones who hesitate are selling a ticket queue.
The managed alternative for most teams
If the risk you are actually carrying is the operational one, the missed backup, the unpatched version, the disk that fills, the connection limit nobody set, then a managed Postgres addresses it directly and a support contract addresses it sideways. The provider takes the backups, applies the patches, sizes the disk, enforces the limit and keeps the instance on a private network with the application. The incidents a contract would help you through mostly do not happen, and the ones that do are the provider’s to handle.
On RunxBuild that is managed Postgres on the general plan ladder, from the $4 Dev plan for development to the $13 BasicMini with 1GB and the $20 BasicPlus with 2GB for production, with backups, user management, documented connection limits and private networking to the services beside it. It is not a substitute for a contributor on retainer when you are tuning a multi-terabyte cluster; it is the thing that means most teams never need one.
How this fits the rest of the stack
The right comparison is not contract versus no contract, it is contract plus self-hosting versus a managed instance, and those are very different monthly numbers. The RunxBuild hosting calculator gives you the managed side of that comparison as line items, the database plan next to the service and the storage, so the figure you put against the vendor quote is complete.
Useful related references:
- PostgreSQL 13 End of Life: Support Ended, So Plan the Upgrade
- PostgreSQL 18: How to Upgrade Without Downtime
- SQLite vs PostgreSQL: Which One Your Project Actually Needs
- Databases on RunxBuild
FAQ
Does PostgreSQL have official commercial support?
No. PostgreSQL is a community project with no owning company, so there is no official vendor. Commercial support is sold by independent companies, many of which employ core contributors, and the project publishes a directory of them without ranking or endorsing any.
What does a PostgreSQL support contract include?
Committed response times by severity, access to engineers through tickets and often phone, help with upgrades, configuration and performance problems, incident review, and sometimes a vendor distribution with backported patches. It adds expertise to your team; it does not run or back up the database for you.
Who needs commercial PostgreSQL support?
Large self-hosted deployments where an hour of downtime costs more than the contract, regulated environments that require a support agreement, teams running unusual configurations or held-back versions, and database administrators who want backup for unfamiliar incidents. A small team with one production database usually does not.
Is PostgreSQL free to use commercially?
Yes. The PostgreSQL licence permits commercial use, modification and redistribution without fees. The costs are the infrastructure you run it on and any support or managed service you choose to buy.
What is the difference between PostgreSQL support and a managed PostgreSQL service?
Support is expertise on call for a database you run yourself. A managed service is a database the provider runs, with backups, patching, monitoring and upgrades handled as part of the product. If your risk is operational rather than diagnostic, the managed service addresses it directly.