What PostgreSQL cost of ownership includes when the license is free
PostgreSQL's license costs nothing to use, so its cost of ownership comes from infrastructure, operations, support contracts and people. The PostgreSQL License is a permissive license similar to the BSD and MIT licenses, so no per-core or per-instance fee applies to running the database itself. Any comparison with a managed service or a commercial database has to price everything around the software, because that is where the money goes.
The work usually starts in one of three situations: a new platform decision, the renewal of a commercial database contract, or a cloud bill review that shows database spend growing faster than the workload. In each case, the team is asked to show the same workload costed end to end on every option. Before building that model, agree on the workload scope, including the number of databases, expected growth, recovery targets and how many environments must be kept running, so that the self-hosted and managed figures describe the same system.
The recurring components are compute and storage for the primary and any standbys, backup storage and WAL archive capacity, network links, a connection pooling layer, monitoring, failover tooling, and the staff hours to run patching and on-call support. One-time components include the initial design, build, testing of backups and failover, and any migration. Major versions arrive about once a year and each is supported for five years, so the upgrade effort recurs on a schedule. The current support window for version 14 ends November 12, 2026, which is an example of a date to put into the model.
Many teams build the cost model in-house, and that is a reasonable choice when they already run databases. The assumptions that move the total most are sizing, the chosen replication mode, the retention period and restore test frequency, and the upgrade approach. Ask any partner or vendor to state those assumptions in writing and to show how each changes the figure. Teams that bring in a partner for these assumptions, along with backup and upgrade planning, get a model they can defend in front of finance and auditors.
What a PostgreSQL cost of ownership review covers
Each card covers one part of the total cost picture, from licensing to the upgrade path. DeployOpen does not set vendor prices. The model is built from the quotes, inventory and staffing data you supply, so every figure traces back to a source you hold and can check.
Licensing and edition options
Covers the PostgreSQL License, which permits use without a license fee, and any commercial distribution or vendor edition you are considering. Check which features, extensions and tooling each edition includes, and confirm the contract term and renewal conditions in writing. Deliverable: a licensing matrix listing each option, what it includes, and the terms you still need to confirm with the vendor.
Infrastructure sizing and hardware
Sizes compute, memory, storage, network and backup capacity for the workload in your own cloud account, data center or air-gapped network. Cost is driven by instance or hardware class, storage throughput, replica count and data growth over the planning period. Deliverable: an infrastructure bill of materials with unit costs taken from your own quotes and inventory, plus the sizing assumptions behind each line.
High availability and backup assumptions
Records the standby count, replication mode, failover manager, backup retention and restore test frequency that the cost model assumes. PostgreSQL provides streaming replication and point-in-time recovery, but it does not detect a primary failure on its own, so failover tooling and its operating effort must be costed separately. Deliverable: an assumptions register stating each availability and backup choice with its recurring cost.
Operations and DBA time
Estimates the people effort for minor release patching, monitoring, tuning, incident response and restore testing, then sets it against the operational scope of any managed alternative. Effort depends on fleet size, change frequency, automation maturity and on-call coverage. Deliverable: an operations effort model that separates one-time setup from recurring hours, with staffing assumptions stated and the current internal hours you should validate.
Support contract options
Compares community support with any commercial support contract, including response expectations, escalation paths, and whether patching and upgrade assistance are covered. Support terms come from each vendor and cannot be inferred from the open-source license. Deliverable: a support comparison table listing each option's coverage, the response terms as quoted, and the renewal pricing trend you should confirm before signing.
Migration and upgrade path
Costs the route to a supported major version and the ongoing upgrade cadence. PostgreSQL releases a new major version about once a year and supports each one for five years, so end-of-support dates drive the schedule. Major upgrades use pg_upgrade or logical replication, and each cycle carries its own effort. Deliverable: an upgrade calendar against end-of-support dates with cost per cycle and open decisions such as cutover window and rollback approach.
What drives PostgreSQL cost of ownership up or down
This table lists the main drivers that move the running cost of a self-hosted PostgreSQL estate, why each one changes cost or effort, and one practical way to keep it lower. Read each row as a lever you can size in your own environment before asking for a quote.
| Driver | Why it moves cost | How to keep it lower |
|---|---|---|
| Data volume and growth | Storage, backup capacity, restore time and the effort of major upgrades all grow with database size and change rate. | Archive or partition cold data and confirm how fast the volume grows before sizing backup storage. |
| Number of databases and clusters | Each cluster needs its own monitoring, backup jobs, patching windows and failover testing, so admin effort grows faster than the data does. | Consolidate small databases onto fewer clusters where isolation requirements allow it. |
| Availability target | A hot standby or synchronous standby adds servers, licenses for support where applicable, and failover tooling that must be tested. | Set the availability target per workload so only critical clusters pay for standbys and a failover manager. |
| Backup and recovery objectives | Tighter recovery point and recovery time objectives need more frequent WAL archiving, more storage and more restore tests. | Agree objectives with the business per system and schedule restore tests at a fixed cadence rather than ad hoc. |
| Connection load | Large numbers of client connections need more memory on the server, and poor pooling can force larger instances. | Add a connection pooler such as PgBouncer so applications share a smaller set of server connections. |
| Number of environments | Every non-production copy repeats installation, configuration, data refresh and patching work. | Use smaller, masked or subset copies for development and test, and automate environment builds. |
| Compliance evidence needs | Assessors expect logs, access reviews, change records and restore evidence, which adds collection and retention effort. | Generate evidence from the standard tooling on a schedule and agree the evidence list with your assessor early. |
| Chosen support model or edition | Community PostgreSQL has no vendor license fee, but in-house DBA time, or a paid commercial distribution or support contract, carries the recurring cost. | Compare in-house DBA hours against a support contract in a written scope and confirm which major version lifecycle dates apply to your plan. |
How a cost of ownership model is built, step by step
The sequence turns a set of PostgreSQL workloads into a comparison of self-hosted community, commercially supported and managed options, with every assumption written down and owned by the people who must defend the numbers.
Inventory current and planned workloads
Start by listing every database that would run on PostgreSQL, including those migrating from Oracle, SQL Server, MySQL or a managed cloud service, and those planned for the next budget cycle. For each one, record the business owner, criticality, data volume, growth expectation, peak connection count, read and write profile, required recovery objectives, and the hours your current DBA or platform team spends on it each month. Also note the PostgreSQL major version in use or planned, because the supported window for each version sets when upgrade work lands. The output is a single inventory sheet with one row per workload and every field filled or marked as unknown with an owner to chase. The step is done when the inventory has been checked against the application portfolio and nothing that depends on a database is missing.
Define the options to compare
Write down the three options the model will compare: self-hosted community PostgreSQL run by your own team, self-hosted PostgreSQL with a commercial support contract from a distribution or vendor, and a managed database service from a cloud provider. For each option, state what is included in the price, what you must still operate yourself, and which controls and features you depend on, such as high availability tooling, backup and point-in-time recovery, connection pooling, authentication integration and monitoring. Confirm with each provider the exact support scope, supported versions and any licensing terms, because commercial terms differ and this document does not set them. The output is a one-page option definition per option that the cost model will reference. The step is done when the platform, security and compliance leads agree that each option is described accurately enough to cost.
Build the cost model with explicit assumptions
Build the model as a spreadsheet or similar file with separate blocks for one-time costs and recurring costs. One-time items include migration or deployment work, tooling setup, and initial hardening. Recurring items include infrastructure or cloud spend, licences or support subscriptions where they apply, backup storage, monitoring, staff time for operations, upgrades, and minor release patching. Every number must link to a named assumption with a source, such as a vendor quote, a cloud pricing page, an internal payroll rate or a measured figure from your environment. Add a sensitivity view for the inputs that move the result most, usually workload size, growth rate, staff hours and support tier. Each assumption should carry an owner and a date. The output is a model where every cell traces to an assumption, and a reader can change one input and see the effect. The step is done when no figure in the summary lacks a source or an owner.
Review the numbers with their owners
Walk each block of the model with the people who own the underlying numbers: infrastructure for hardware and storage, finance for rates and licence terms, the DBA or platform lead for operational hours, security for controls such as backup testing and access management, and the application owners for workload forecasts. Ask each owner to confirm or correct their inputs, and record every change in a log with the reason. Pay particular attention to items that are easy to omit, such as the staff time spent on major version upgrades, restore testing, connection pool tuning and incident response for a self-hosted cluster, and the cost of any failover tooling you would build or buy. The output is a reviewed model with a change log and a list of open items, each with an owner. The step is done when every owner has confirmed their block in writing.
Hand over the model with a refresh plan
Deliver the model with a short guide that explains how the structure works, which assumptions are most sensitive, where each source lives, and who is responsible for updating each input. Agree a refresh routine tied to real events: a new PostgreSQL minor or major release, a change in a supported version date, a new support or cloud pricing change, a workload added or retired, or a change in staffing. Record the next review trigger in the same document. Explain to the sponsor which decisions the model supports and which it does not, such as an architecture choice that still needs a proof of concept or a compliance question that needs an assessor. The output is the handed-over model, its guide, and a named owner for each refresh trigger. The step is done when the sponsor and the model owner can each explain the top three drivers of the result without help.
How managed PostgreSQL pricing compares with running it yourself
The structural difference between the two options is who pays for operations. PostgreSQL is released under the PostgreSQL License, so the software carries no license fee. A self-hosted cluster still costs money in four places: the compute and storage it runs on, the staff hours spent on minor-version patching, major upgrades, backup and restore testing and failover, any paid support contract, and the monitoring tools your team chooses. Most of these recur every year. Staff time is the cost teams most often miss, because it is spread across existing platform and database roles and seldom appears as a separate line in the budget.
A managed service bundles many of those operations into a service fee, usually charged by instance size, storage, replica count and, in some cases, backup storage or data transfer. What the fee includes varies by provider. Ask for written pricing for your region, your storage size, your replica layout and your backup retention period. Then confirm in writing whether backups, automated failover and minor-version patching are included, how long backups are kept, and whether a restore into a new instance carries an extra charge. Compare the two options using the same topology, not the cheapest advertised tier.
A managed service does not remove the work that stays with your team. Schema design, index strategy, query tuning, connection handling and configuration for your workload remain your responsibility, and so do the effects of slow or poorly designed queries. Exit terms and data egress often matter most at the end of the relationship. Check which export formats are available, what it costs to move a full dump or base backup out of the provider, and whether logical replication to another PostgreSQL host is supported for a low-downtime cutover. These items are often the largest unpriced costs in a multi-year comparison.
To make the comparison useful, build one model with identical topology for both options. Include the primary, standbys, backup storage at your chosen retention, expected transfer volume, and an estimate of staff hours for each recurring task. For self-hosting, note that minor releases arrive at least once every three months, so patching is a standing load, and that each major version is supported for five years after its initial release, so upgrades must be scheduled inside that window. For the managed option, ask which major versions the provider offers and when it retires them, because its schedule may differ from the community end-of-life dates. Share the model with finance and the platform team before deciding.
Recurring PostgreSQL cost of ownership after go-live
This table lists the recurring PostgreSQL cost lines that continue after go-live, showing whether each one is fixed or scales with data or load and who pays for it. Read the middle column to judge how each line grows, and use the last column as the item to confirm in a quote. The main takeaway is that the PostgreSQL License carries no license fee, but a major upgrade recurs roughly every five years for each version under the supported lifecycle.
| Cost line | Fixed or scales with | Who pays | What to confirm |
|---|---|---|---|
| Compute and storage for primary and standbys | Scales with data volume, write load and replica count | Your infrastructure budget, cloud or data center | Sizing assumptions and growth forecast behind the quote |
| Backup storage and WAL archive retention | Scales with data change rate and retention period | Your storage budget | Retention period and how often restores are tested |
| Monitoring and log tooling | Mostly fixed, grows with host count and log volume | Your team, or a licensed tool vendor | Licensing model and whether it bills per host or per volume |
| Connection pooling capacity | Scales with peak client connections, fixed per pooler host | Your infrastructure budget | Pooler sizing against peak connection counts |
| Support or subscription with a commercial distributor | Fixed per contract term, may scale with cores or nodes | You, under the contract | Terms, covered scope and renewal with the vendor, not assumed |
| Internal DBA or platform time for minor releases | Recurs each quarter, grows with the number of clusters | Your payroll, or a retained partner | Minor releases ship at least every three months per the versioning policy |
| Planned major upgrade cycle | Recurs about every five years per version, scales with database size and downtime tolerance | Your team or a partner, one time per upgrade | Version 14 supported through November 12, 2026; version 18 through November 14, 2030 |
How the cost model changes by starting point
When the current database is commercial, the license line is the most visible change, but the model also has to price the features that the old contract supplied. PostgreSQL is released under a permissive license, so the new license line is zero, and the cost moves into conversion, migration, tooling and skills. The license comparison is the starting input, and it has to be a like-for-like inventory of what the current contract covers.
- Licensing comparison: list each licensed component, the core or processor basis, support tier, renewal date and any run-off or overlap terms.
- Schema and code conversion: the one-time effort to convert procedural code, data types and vendor-specific SQL. It grows with the volume of procedural logic.
- Data transfer and validation: one-time work for tooling, parallel running and reconciliation, driven by data volume and the downtime the business accepts.
- Replacement tooling: monitoring, backup and high availability features that the commercial product bundled and that you now source, build or staff.
- Sequencing decision: whether this is a full replacement or a phased move that keeps some commercial systems running for a period.
Confirm with your vendor whether the contract allows partial termination, because that sets how long you carry overlap cost.
Community PostgreSQL publishes fixes only for supported major versions. The community policy supports each major version for five years after its initial release. Version 14 is supported until November 12, 2026, and version 13 and earlier are no longer supported. Staying on an unsupported version turns the upgrade into a recurring risk cost, and the model has to show when that cost becomes unavoidable.
- Support source: the community project does not offer extended support for unsupported versions. Any third-party support for an old version is a separate quote to request, with its term and scope in writing.
- Upgrade method: pg_upgrade, a dump and restore, or logical replication. The documentation notes that logical replication works across major versions with only several seconds of downtime, but it requires extra setup and monitoring.
- Testing effort: application compatibility testing and a rehearsal of the upgrade, which usually costs more than the upgrade command itself.
- Target sizing: new hardware or capacity for the target version, and in PostgreSQL 18 the parallel jobs option in pg_upgrade may change run time.
- Target version and date: the decision on which major version to target and when, measured against its end-of-life date.
Before finishing the model, ask for the planned end-of-life dates of every version in your fleet, since each one creates a separate upgrade line.
On Kubernetes, the cost model moves away from virtual machine lines and toward platform lines. Cluster capacity, storage performance and the operator you choose now carry most of the recurring spend. PostgreSQL does not include its own failover detection, so the model must include the external components that provide it, along with the staff who operate them.
- Operator choice: the operator's license, support model and release cadence. Confirm whether support is community-based or sold by a vendor, and what it covers.
- Persistent storage: storage class performance, volume size and snapshot capacity, which often drive cost more than CPU for database pods.
- Node capacity: room for primary and standby pods, plus spare capacity so that a node failure does not leave the cluster unable to schedule a replacement.
- Platform skills: time from the platform team on Kubernetes scheduling, storage and upgrades, which is shared with other workloads and needs an allocation rule.
- Ownership decision: whether the platform team or the database team owns the operator and its upgrades, which determines who pays for the on-call work.
Ask for the operator's support terms in writing, and confirm them against the versions you plan to run, since operator compatibility varies by PostgreSQL release.
In an air-gapped or heavily regulated network, the cost of a patch is not the cost of the package. The model has to include the offline mirror, the transfer process, the approval path and the evidence each change leaves behind. The license line stays at zero, but the recurring effort of keeping a closed network current is often the largest component of the model.
- Offline package mirror: the infrastructure and maintenance of a mirror that receives PostgreSQL and dependency packages, and the process for verifying their integrity before import.
- Minor release cadence: the project publishes minor releases at least once every three months, and each one needs testing, a change record and a restart window.
- Approval and change control: the time required by security and change boards to approve each update, which should be counted per release cycle.
- Evidence collection: logs, configuration records and test results that auditors will ask for. DeployOpen prepares systems and evidence for assessments, but independent auditors issue any report.
- Identity and key management: the effort to integrate authentication with the internal directory and certificate authority, which is usually one-time but recurs when certificates renew.
Confirm with your security team how many change windows per year they will approve, because that sets the realistic frequency of patching and the recurring cost that follows.
Where PostgreSQL cost estimates usually go wrong
Most PostgreSQL estimates understate cost in the same few places: the license, storage beyond the primary, recurring maintenance, the next major upgrade, connection handling and mismatched comparisons. Each card names one of these gaps and the check that closes it. Use the list as a review checklist before any budget is approved.
Treating the license as total cost
The PostgreSQL License carries no license fee, so the software line in a budget is often zero. The real cost sits in servers or cloud instances, storage, monitoring, backup tooling, staff time and any commercial support contract you choose. Prevention: list every component the platform needs, price each one separately, and show the license as a zero line so reviewers can see what remains.
Leaving out standby and backup storage
A production cluster often includes one or more standbys, since hot standby servers serve read-only queries and support failover. Each standby needs its own compute and storage, and base backups plus archived WAL files add retained data for point-in-time recovery. Prevention: size storage for the primary, every standby, base backups, WAL retention and any incremental backups as separate lines, and confirm retention periods against your recovery objectives.
Omitting DBA time for patching
PostgreSQL releases minor versions at least once every three months. Applying one means replacing executables and restarting the server, which also requires testing, a change window and rollback planning. This labor recurs for the life of the cluster, so it belongs in the annual figure. Prevention: budget hours each quarter for minor releases, name the accountable owner, and state whether the estimate assumes internal staff or a retained support contract.
Underestimating the major upgrade
Each major version receives support for five years from its initial release. Version 14 is supported until November 12, 2026, so a cluster still running it has a fixed deadline. Major upgrades use pg_upgrade, a dump and restore, or logical replication, and the method you pick changes downtime and effort. Prevention: schedule the upgrade as a funded project with a testing phase completed before the end-of-support date.
Ignoring connection pool capacity
Applications that open many direct connections can exhaust connection limits and memory on the database host. A pooler such as PgBouncer sits between clients and the server, which changes how the database host is sized and adds a component that needs its own monitoring, patching and failover design. Prevention: count peak client connections per application, choose a pooling mode, and add the pooler hosts and their maintenance to the estimate.
Comparing managed and self-hosted prices
A managed quote and a self-hosted estimate often differ in vCPU count, memory, storage type, replica count, backup retention, support level and billing period. A mismatched comparison can make either option look cheaper than it is. Prevention: put both options on the same configuration and period, including high availability, backups and support, then assign an owner to each assumption, such as the person who confirmed the storage size or the retention period.
What the client needs to provide for an accurate estimate
An accurate PostgreSQL cost model starts with an inventory of what you run today. For each cluster, list the database names, the major version, the data size on disk, the monthly growth rate and the number of instances, including standbys and any reporting copies. Storage, backup capacity, replication bandwidth and the hardware or instance sizes all follow from these numbers. The version matters as well: the PostgreSQL versioning policy lists version 14 as supported until November 12, 2026, and versions 13 and earlier are unsupported, so a current estate on an older release adds an upgrade project to the estimate. Without sizes and growth, the model can only describe a single day, not the three-year cost of ownership. Ask the database platform owner to supply this list and to confirm the growth figures from the last twelve months of storage metrics.
Next, the availability and recovery targets decide how much infrastructure you need. Record the recovery time objective and recovery point objective for each system, whether a failed primary may be replaced automatically, and whether commits must wait for a standby. Synchronous replication, asynchronous replication and hot standby reads each change the node count and the hardware. PostgreSQL does not detect a failed primary by itself, so any automatic failover requires an external tool, and that tool's licensing, support and testing time must appear in the estimate. Without stated targets, the model either overbuilds every database or quietly assumes a lower service level than the business expects. The service owner of each system should sign off on these targets, because they are business commitments, not engineering preferences.
Connection counts and workload shape are the third input. Ask for peak and typical numbers of client connections per database, the number of application servers that open them, and whether reporting or analytics queries run against standbys. Many connections raise memory needs on the primary, and a connection pooler in front of PostgreSQL may reduce the instance size you need, but it adds a component to build, monitor and patch. The application team owns the connection figures and should confirm them from connection logs or pool settings rather than from memory. Without them, the estimate cannot size memory or decide whether pooling belongs in the baseline or in an optional line item.
Current spend shows what the change will replace. The PostgreSQL License carries no license fee, so for community PostgreSQL the cost is in infrastructure, labor and tooling. If you use a commercial distribution, a support contract or a managed cloud database today, provide the invoices for the last twelve months, itemized by instance, storage, backup, support tier and data transfer. Also provide your cloud or data center rates: compute, block storage, object storage for backups, network egress, power, rack space and hardware refresh cycles. Name the finance owner for these rates. Without itemized invoices, a comparison with managed services will mix recurring and one-time costs, and the result will not hold up in a budget review.
Staff roles and compliance requirements complete the picture, and both need named owners. List who performs database administration, who is on call, who patches the operating system and who approves changes, together with the hours each role spends on the database each month. Then list the compliance obligations that apply, such as audit log retention, encryption expectations, data residency and access review frequency, and ask the compliance lead to confirm them in writing. These drive tooling, log storage and recurring review effort. Each assumption in the model should have one named owner who confirms it. Finally, the sponsor must approve the chosen configuration, including node count, recovery targets and support model, before the model is treated as a budget. Until then, it is a basis for discussion.
Questions buyers ask about PostgreSQL cost and editions
Does PostgreSQL itself cost anything to license?
No license fee applies to the PostgreSQL software itself. PostgreSQL is released under the PostgreSQL License, a permissive open source license similar to the BSD and MIT licenses, so you can run, modify and redistribute it without royalties.
Your spending goes to the parts around the software: servers or cloud capacity, storage, backup targets, monitoring, the staff who operate the cluster, and any support contract you choose to buy. Extensions and bundled tools carry their own licenses, so ask your legal or procurement team to review those before you add them. For most budgets, infrastructure and staff time are the recurring lines to model first.
What does a commercial PostgreSQL distribution or support contract add?
A commercial distribution or support contract adds a vendor obligation on top of the community software. Typical elements include response commitments, help with production incidents, packaged or validated builds, and any tooling the vendor bundles.
Confirm in writing which major versions the vendor covers, how far back patches reach, and how severity levels and response times are defined. Ask for pricing based on the units the vendor uses, such as cores, clusters, or standby and disaster recovery nodes. The community project supports each major version for five years after its initial release, so compare the vendor's support window against that before you sign.
How does self-hosted PostgreSQL compare with a managed cloud database?
Self-hosted PostgreSQL usually avoids a service premium but moves operations work to your team. A managed database bills for an instance, storage and a service fee, and the provider takes on part of the patching, backup scheduling and failover tooling. The scope of that help differs by provider.
Self-hosting means paying for compute, storage, backup targets, replicas, monitoring, and staff time for failover testing, minor releases and major upgrades. Ask each managed provider to quote instance sizes that match yours, plus storage, IOPS, backup retention, cross-region copies, data transfer, and which high availability and point-in-time recovery features are included. Compare both models over the same period and include the staff hours.
What drives the effort and time to run PostgreSQL in production?
The main drivers are the number of clusters, how tight your recovery objectives are, and how many systems connect to the database. Each replica, failover path, backup chain, connection pooler and monitoring stack adds design, build and test work, and each needs a named owner afterward.
Upgrades add recurring effort. Minor releases arrive at least once every three months, and each major version is supported for five years after release. Supported versions run from 14 (until November 12, 2026) to 18 (until November 14, 2030), so plan each major upgrade before a cluster reaches end of support. Data volume, the migration source, and the amount of custom SQL in your applications also change the timeline. Ask for the effort breakdown by workstream in any quote.
Can our own team build the PostgreSQL cost model in-house?
Yes, a capable team can build the model in-house if it has the inputs and the time. Start with an inventory of databases, data sizes, growth rates, peak connection counts and recovery objectives. Size production, standby and backup capacity from that inventory.
Add staff time for the build, testing, on-call coverage, monthly patching, and the major upgrade due within each five-year support window. Replace your assumptions with current quotes for hardware, support contracts and managed database pricing. Run a failover drill and a restore test, since those often expose hours that a spreadsheet misses. If your team lacks a DBA with production failover experience, a scoped external review can check the model before you commit.
Which PostgreSQL version should we pick to limit upgrade work?
Pick the newest major version your applications and extensions support, and plan the upgrade path before you deploy. Version 18 was first released on September 25, 2025 and is supported until November 14, 2030. Version 14 is supported until November 12, 2026, so it is the version to plan away from first.
Because each major version receives five years of support and a new major version arrives about once a year, expect a steady upgrade cadence. Choose the upgrade method early. pg_upgrade and logical replication are the two common paths. Logical replication works between major versions and, in the documented approach, allows an upgrade with only several seconds of downtime, which depends on your workload. Minor releases do not change the storage format, so they usually mean replacing executables and restarting. Confirm with each extension vendor which major versions they support.
What does the team need to provide before a PostgreSQL quote can be written?
A quote follows from a written scope, so the first step is giving us the facts that define it. Provide the list of databases and applications, current data sizes and expected growth, peak connection counts, and the recovery point and recovery time objectives agreed with the business. Describe the hosting environment, whether cloud accounts, data centers or air-gapped networks.
Name the identity system logins should use, any compliance obligations that shape logging and retention, and the change windows your teams accept. Tell us who will operate the cluster afterward and what on-call coverage exists. Share any current licenses or support contracts you hold. DeployOpen does not publish a price list. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Is ongoing PostgreSQL support included after the initial build?
Ongoing support is not assumed to be part of the initial build, so confirm it in the written scope. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the coverage and fees are set in the agreed scope.
A retainer can cover the recurring work this page describes: applying minor releases, planning and running major upgrades before end of support, reviewing backups and running restore tests, and handling incidents within agreed hours. Ask for the exact list of covered tasks, response expectations, escalation paths, and which items are billed separately, such as emergency work or major upgrades. DeployOpen does not publish prices, so a retainer quote follows from the same written scope.
How DeployOpen builds PostgreSQL cost models with you
DeployOpen builds the PostgreSQL cost model with your team against a written scope. Each model separates the community software, which carries no license fee, from support, hardware, tooling, DBA time and the recurring upgrade and backup work that comes with each major version. DeployOpen does not publish a price list, so a quote follows from the scope you approve.
How we scope
- The written scope names the PostgreSQL versions, editions and support tiers being compared.
- It records the hosting model, whether in your cloud accounts, data centers or air-gapped networks.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- Model the license-free core against commercial support, hardware, tooling and DBA hours.
- Map upgrade and minor release effort to the five-year support window of each major version.
- Compare a managed database alternative on the same assumptions, and list what it excludes.
How we hand over
- A cost workbook with assumptions, formulas and the version dates each line depends on.
- Written notes separating one-time costs, such as setup and migration, from yearly recurring costs.
- A list of quote questions for vendors and managed providers, so comparisons use matching scope.
How we support
- An optional retainer covers ongoing DBA support, minor release patching and major upgrade planning.
- Revisit the model as each major version nears its end-of-support date, such as version 14 in November 2026.
- Confirm pricing, support terms and licensing with each vendor directly, since these change over time.
