Database licensing invoices tend to climb every year, even when the workloads running on them haven't changed. Support fees increase on their own schedule. Per-core or per-user counts creep up as infrastructure grows. Add-on options that were enabled for one project years ago stay on the license count. Then there's the audit, which can turn a routine budget review into an unplanned true-up. 
That decision changes more than the invoice. PostgreSQL's open-source foundation removes the per-core license count that audits get built around, along with the single-vendor pricing dependency that comes with proprietary licensing. Fujitsu Enterprise Postgres adds enterprise support and security on top of that foundation without reintroducing either constraint.
This guide covers both paths to reducing database licensing costs. It starts with the contract-level levers available right now, then makes the structural case for standardizing suitable workloads on PostgreSQL.
Why database licensing costs keep rising
Proprietary database licensing is priced by units that scale with infrastructure, not with how much the database actually gets used. Per-processor and per-core metrics count every core a workload could run on. Named-user metrics count every person with access, whether they log in daily or never. Neither metric moves in the direction an IT budget wants it to.
The number in the original business case is rarely the number on this year's renewal, and the gap compounds for a few predictable reasons. Annual support fees increase year over year, often independent of any change in how the software is used. Add-on options and features get enabled for a single project and never get removed from the license count, even after the feature falls out of active use. Hardware refreshes add licensable cores without anyone rechecking whether the new environment needs the same tier and options as the old one. Virtualization and cloud deployment often license more infrastructure than a workload is actually using at any given time. Mergers, acquisitions, and organic application growth quietly expand the license count an organization is contractually required to carry, well ahead of anyone revisiting whether that count still matches deployed reality.
Audits sit on top of all of this, and they're no longer a rare event. 62 percent of enterprises reported being audited by a major software vendor within the past year, and nearly a third of those audits produced liabilities exceeding $1 million.
None of these drivers are unusual. They're a normal feature of how proprietary database licensing works, which is why the cost curve rarely flattens without deliberate intervention.
Ways to reduce database licensing costs within your current footprint
The levers below reduce spend inside the current environment. Each one is worth doing on its own merits, independent of whether a larger migration is on the table.
Auditing usage and eliminating shelfware
Most enterprises carry licenses tied to decommissioned servers, retired applications, or environments nobody actively uses anymore. Nobody budgets for this on purpose. It accumulates quietly, one decommissioned project at a time, until the license inventory no longer resembles what's actually running. A license audit against actual deployment, rather than against what procurement records show, routinely turns up licenses that can be terminated at the next renewal without touching a single production workload.
Right-sizing editions and licensing metrics
Premium or top-tier editions carry a materially higher list price than a lower, standard tier. Workloads that don't need the premium tier's advanced features are often licensed on it anyway, usually because that's what the original purchase defaulted to and nobody revisited the decision since. Named-user pricing beats per-processor licensing for environments with a small, countable user base, while per-processor licensing wins once user counts climb higher. Matching the metric to the actual usage pattern, rather than to whatever the original purchase locked in, is a straightforward audit-level fix.
Reviewing licensed options you don't use
Add-on options such as partitioning, advanced security features, or high-availability clustering are often priced per processor and licensed for every core running the database, whether or not the option is actively in use.
A team enables one of these for a single project, the project ships, and the option stays on the license inventory indefinitely because removing it never became anyone's job. Reviewing the full option stack against what's genuinely deployed is often a larger line item than shelfware alone, since options compound the base license count rather than sitting beside it.
Renegotiating support and timing agreement exits
Support renewals are negotiable more often than the contract language suggests, particularly when consolidating multiple vendor contracts or timing a renewal against the vendor's own fiscal year-end. Organizations that move stable, well-understood estates to third-party support report meaningful savings, though it comes with trade-offs around patching and update rights worth weighing first.
Unlimited-use licensing agreements add a different wrinkle. They cap cost during the term, but the exit certification process determines what an organization actually owns once the agreement ends. Timing that exit against real deployment, rather than the contract's own renewal date, is where the leverage sits, and none of this requires a formal audit to force the conversation.
The limits of contract-level optimization
These levers reduce spend. They don't change what's driving it. The per-unit pricing model, the annual support escalation, and the option stack all persist. Every optimization inside a proprietary licensing agreement has a ceiling, and it's the same one enterprises hit renewal after renewal. It trims the bill without touching the dependency the bill is attached to.
The structural lever: standardizing workloads on PostgreSQL
Migrating suitable workloads to enterprise PostgreSQL changes the cost structure rather than trimming it. Migrated workloads no longer require per-core licensing and its associated support costs, although organizations should account for migration, operations, and enterprise support costs on the target platform when evaluating the overall business case.
This isn't a wholesale rip-and-replace, and treating it as one is usually how these programs stall. Selective standardization works better in practice. Workloads with lower application coupling, standard SQL, and limited use of vendor-specific procedural code typically move first, while highly customized, tightly coupled systems can stay in place longer while the migration program builds momentum elsewhere.
Teams that have gone through this transition, including some who've written candidly about what surprised them along the way, tend to agree on the same lesson. Sequencing matters more than speed.
| Approach | Short-term savings | Long-term impact |
| Audit and shelfware removal | Low to moderate | Limited — footprint and pricing model unchanged |
| Right-sizing editions and metrics | Moderate | Limited — same model, smaller base |
| Options review and de-licensing | Moderate | Limited — recurring cost persists on the remaining footprint |
| Standardizing workloads on PostgreSQL | Lower in year one, due to migration cost | Structural — per-core fees removed for migrated workloads |
What enterprise-grade PostgreSQL preserves that cost-cutting can't sacrifice
Reducing spend can't mean reducing operational assurance, and that tradeoff is where migration programs earn or lose credibility with the people who have to sign off on them. Whatever workloads move onto PostgreSQL still need support SLAs, security and audit capabilities, compliance controls, and lifecycle management once they land there. Lifecycle management matters as much as the migration itself. Predictable maintenance windows, upgrade planning, and how long a given PostgreSQL version stays supported all affect a platform's real long-term cost, not just its license price.
How much of that assurance an organization gets depends on which platform form it chooses, and this is usually where the decision gets harder than it first looked. Community PostgreSQL puts support and lifecycle management entirely on the internal team. A hyperscaler-managed service handles some of the operational burden but ties the workload to that provider's infrastructure, a trade-off that applies to the major cloud-managed PostgreSQL offerings alike.
An enterprise distribution such as Fujitsu Enterprise Postgres on IBM Power builds support, security engineering, and lifecycle management into the platform itself. Fujitsu Enterprise Postgres, for example, is a 100% PostgreSQL-compatible enterprise distribution that layers transparent data encryption, data masking, and dedicated audit logging on top of the open-source engine, backed by 24/7 global support, at a structurally lower cost model than proprietary per-core licensing.
Fujitsu's migration and support services cover both the move itself and what happens after it.
Building the business case: from licensing relief to standardization
Budget owners sequence this decision the way they'd evaluate any infrastructure investment. They quantify the current state, model the full cost of the alternative, and check the payback period before committing to anything. On the current-database side, that means license fees, support costs, option spend, and audit exposure. On the PostgreSQL side, it means migration costs, infrastructure changes, operational costs, and training. Weigh that against ongoing enterprise support, the licensing costs that go away, reduced vendor lock-in, and the risk reduction of moving off a database whose renewal costs only move in one direction.
The gap between those two columns is usually theoretical until someone runs a structured migration assessment. That's what turns which workloads qualify for the first wave, what migrating them actually costs, and what payback period that implies, from a guess into a number a budget owner can actually defend. A global superannuation platform used exactly this approach, replacing its existing database environment after a structured architecture review and migration assessment, and completed the move over a single weekend. The migration saved the company millions of dollars and improved database performance in the process.
Ask Fujitsu's specialists for a Database Migration Assessment that quantifies which workloads you can move to enterprise PostgreSQL, and what the licensing relief looks like net of migration cost.
Frequently asked questions about reducing database licensing costs
How is enterprise database licensing typically priced?
Most proprietary databases license by processor, core, or named user, with support billed separately, usually as a percentage of the license fee that renews annually. Add-on options such as high availability or security features are typically priced the same way. Actual terms vary by vendor and negotiated discount.
Can I cancel support on unused database licenses?
Usually only at renewal, and only for licenses shown to be genuinely unused. Most proprietary vendor contracts require an all-or-nothing approach to a license set rather than partial cancellation, which is why this works best alongside a broader audit that identifies exactly which licenses to drop.
Why is proprietary database licensing so expensive?
The cost compounds across layers. A high per-processor or per-user list price, an annual support fee that rarely falls, a wide catalog of add-on options, and licensing rules around virtualization that can require licensing more hardware than a workload actually uses all add cost independently of each other.
How much can migrating to PostgreSQL save on licensing costs?
Savings vary by workload and starting platform, but organizations that have standardized suitable workloads on enterprise PostgreSQL report licensing cost reductions in the range of 50 to 80 percent. The realistic net figure depends on migration cost and ongoing support, which is why a structured assessment beats a rule-of-thumb percentage.
Which workloads should move to PostgreSQL first?
Workloads with standard SQL, limited use of vendor-specific procedural code, and limited application coupling are usually the best early candidates. Highly customized or tightly coupled systems typically take longer to convert and are better sequenced later, once the migration program has momentum from earlier, lower-risk moves.
What's the difference between proprietary DB licensing and PostgreSQL's model?
Proprietary databases license per processor or named user, with support and options priced separately. PostgreSQL carries no per-core license fee, but enterprise deployments still need a support and security model. Comparing Fujitsu Enterprise Postgres against community PostgreSQL shows where that model earns its cost, through support rather than per-processor fees.
Is PostgreSQL suitable for enterprise production workloads?
Yes. PostgreSQL runs production workloads across finance, government, and other regulated industries today, particularly with enterprise support, security features, and compliance controls layered on through databases like Fujitsu Enterprise Postgres. The question for most enterprises isn't whether PostgreSQL can handle the workload, but which support and governance model fits.
How do I calculate potential database licensing savings?
Start with current spend across licenses, support, options, and audit exposure, then estimate migration cost plus ongoing support on the target platform. A structured migration assessment runs this calculation with real numbers, comparing net savings against migration cost to produce a payback period specific to the environment.
Can applications built on another database run on PostgreSQL?
Most applications can, but not usually without changes. Applications built on standard SQL with limited vendor-specific procedural code port with limited rework, while those relying on proprietary-specific features need more substantial conversion. The application layer, not the database engine, usually decides how much work a given migration takes.
Should every database be migrated to PostgreSQL?
No. Migrating every workload isn't the goal, and treating it as one is usually how these programs stall. Workloads with standard SQL and limited application coupling are strong candidates. Highly customized or tightly coupled systems often make more sense to keep in place while the program builds early momentum.
PostgreSQL Insider 
