One hundred and forty databases, far fewer licensed cores
An insurance company runs about 140 Oracle databases on 60 servers, accumulated one project at a time over fifteen years. Licence support is the largest line in the database budget, and most of those cores are idle most of the day. This design consolidates the databases that must stay on Oracle onto a small, dedicated estate, moves the ones that can to PostgreSQL, and gives everything proper HA, DR and backup on the way.
Licensed for peak on every server, busy on almost none
The insurer writes life and health policies through agents, bancassurance partners and its own portal. Policy administration and claims run on packaged software certified only on Oracle. Around them sit dozens of in-house applications, portals, reporting systems and integrations, each of which got its own Oracle database, and often its own server, when it was built.
Today there are about 140 databases on 60 servers, on Oracle versions from 11g to 19c. Licences are counted on roughly 960 physical cores. Average CPU use across those servers is about 22%. Some servers are past hardware support, backups are run differently on almost every one, and only the policy and claims databases have a tested standby.
The CFO’s question was direct: how much of the Oracle bill pays for capacity that nobody uses, and how much could be avoided without putting policy servicing or claims at risk? The CIO added a second one: can the result be something the DBA team can actually run, with one way of doing backup, HA and DR?
What could not be compromised
- Policy administration and claims stay on Oracle. The vendor certifies nothing else.
- No change can put the licence position at risk. Every step is checked against the contracts actually held.
- IRDAI requirements on record keeping and information security, and the DPDP Act for policyholder data, apply throughout. Data stays in India.
- Policy servicing runs from 7 am to 11 pm. Cut-overs happen at night or on weekends, inside agreed windows.
- A DBA team of eight, strong on Oracle, with little PostgreSQL experience today.
Four ways to reduce the database bill
Each option was modelled over five years using the licence baseline, measured database load and an application-by-application review of what could change.
A small Oracle estate for what must stay, PostgreSQL for the rest
Oracle runs on four dedicated physical servers at the primary site and three at the DR site, sized from measured load. PostgreSQL runs as three highly available clusters grouped by tier. Applications reach both through an access layer of service names and connection pooling, so a database can move without changing application settings.
| Building block | Why it is there |
|---|---|
| 1 Licence baseline | Before anything moves, every server, core count, edition, option and management pack in use is listed and reconciled with the contracts held. This becomes the reference for every later decision. |
| 2 Consolidated Oracle estate | Seventy databases on four dedicated physical servers. Container databases are used where the licence allows; the number of pluggable databases allowed without the extra-cost option is limited, so this is checked against the licence held, and separate instances are used otherwise. |
| 3 PostgreSQL platform | Three clusters of three nodes, managed with Patroni for automatic failover inside the site. Databases are grouped by tier, so a busy reporting database never shares a cluster with a customer portal. |
| 4 Conversion and change data capture | Schema conversion tooling handles most tables, views and simple procedures. Heavier PL/SQL is rewritten by hand or moved into the application. Changes stream from Oracle to PostgreSQL until cut-over, so the switch takes minutes. |
| 5 Database access layer | Applications connect through service names and connection pooling, not server addresses. Moving a database or failing over changes the target behind the name, not the application. |
| 6 HA and DR | Tier 1 Oracle databases have a standby on a second server in the same site and another at DR. PostgreSQL clusters keep a synchronous replica in the site and stream to replicas at DR. |
| 7 Backup, encryption and audit | One backup service for both platforms, with immutable copies at DR. Data is encrypted at rest with keys in a central vault. Access and licence-relevant usage are monitored continuously. |
Sized from measured load, then checked against the licence
AWR reports and 90 days of server metrics were used for every Oracle database. Newer processors do roughly 1.6 times the work per core of the oldest servers in the estate, which matters when licences are counted per core.
| Item | Today | Design | Basis |
|---|---|---|---|
| Databases | ~140 | ~70 Oracle, ~52 PostgreSQL, ~18 retired | Application-by-application review with owners |
| Oracle load at p95 | ~210 busy cores across 60 servers | ~150 cores for the databases that stay | Measured; the 52 moving databases account for the rest |
| Oracle primary | 960 licensed cores, all servers | 4 servers x 48 cores = 192 cores | 150 / 1.6 = ~95 cores on new CPUs, +40% growth = ~133, carried by 3 servers |
| Oracle DR | Standby for 2 systems only | 3 servers x 48 cores = 144 cores | Carries the full Tier 1 and Tier 2 load in a disaster |
| Licensed Oracle cores | ~960 | ~336, about 65% fewer | 192 primary + 144 DR, standby cores counted as licensed |
| PostgreSQL | - | 9 nodes x 16 cores, 3 at DR | ~45 busy cores today, ~30 on new CPUs, one primary per cluster with room to grow |
| Storage | ~48 TB of data on local and SAN disks | ~70 TB usable all-flash per site | ~44 TB after retirement, +50% growth, separate from backup |
The licence figures are design targets. The final position depends on the contracts, options and support terms in place, and is confirmed with the company’s licensing team and a licensing specialist before any server is decommissioned.
Licence first, then the platform, then the databases
Nothing moves until the licence baseline is agreed. Databases then move in waves grouped by application, with policy and claims last.
Licence baseline and assessment
Weeks 1 to 8
Every database, server, edition, option and pack catalogued and reconciled with contracts. Each database assessed: stay on Oracle, convert, or retire.
Gate: Baseline signed off by finance, procurement and IT. Every database has a target and an owner.
Build the platform
Weeks 9 to 18
Oracle and PostgreSQL platforms at both sites, access layer, backup, encryption and monitoring. DBA team trained on PostgreSQL alongside the build.
Gate: Failover and restore tests passed on both platforms, with times measured.
Retire and pilot
Weeks 19 to 24
Eighteen unused databases archived and switched off. First ten in-house databases converted to PostgreSQL with their applications.
Gate: Pilot applications run a full month-end on PostgreSQL with no data issues.
Migration waves
Weeks 25 to 46
Remaining PostgreSQL conversions and Oracle consolidation in four waves, grouped by application. Policy admin and claims move last, using a standby at the new estate and a switchover.
Gate: Each wave stable through one month-end before the next starts.
Decommission and true-up
Weeks 47 to 52
Old servers wiped and removed. Licence position recalculated and support terms renegotiated.
Gate: Licence position documented and agreed. DR test passed for every tier.
Where database consolidation goes wrong
| Risk | What could happen | How the design handles it |
|---|---|---|
| Licence exposure | A consolidation step increases the licence requirement instead of cutting it | Oracle runs only on dedicated physical servers, because the vendor’s partitioning policy does not accept most general-purpose virtualisation for limiting licensed cores. Every design change is checked against the baseline. |
| Support repricing | Dropping unused licences from support raises the price of those that remain | The savings case is modelled with and without repricing, and negotiated before any notice is given. |
| Conversion surprises | PL/SQL or Oracle-specific features make a conversion far larger than estimated | Every database is scanned for features before it is assigned. Anything heavy stays on Oracle rather than delaying the programme. |
| Noisy neighbours | A heavy batch job slows policy servicing on a shared server | Databases grouped by tier, with resource limits per database and batch scheduled outside servicing hours. |
| Skills | The DBA team cannot support PostgreSQL in production | Training during the build, runbooks written with the team, and pilot databases run by them before the first production wave. |
Where the savings come from
Fewer licensed Oracle cores
From about 960 to about 336, including DR, by sizing from measured load on newer processors.
Databases with no licence cost
In-house databases that do not need Oracle move to PostgreSQL.
Databases retired
Unused and duplicate databases are archived and switched off, not migrated.
Fewer database servers
Sixty servers become 7 Oracle and 9 PostgreSQL servers across two sites.
Way to back up and recover
One backup service and one set of runbooks for both platforms.
Licence visibility
Options and packs in use are monitored, so the licence position never drifts.
What the design is built to deliver
| Measure | Before | Design target |
|---|---|---|
| Licensed Oracle cores | ~960 | ~336, subject to contract review |
| Annual Oracle support cost | Largest database budget line | 40 to 55% lower, depending on support renegotiation |
| Database servers | 60 | 16 across primary and DR |
| Databases with tested DR | 2 systems | All production databases, by tier |
| Recovery for policy and claims | RPO about 15 minutes, RTO about 8 hours | RPO under 1 minute in site, under 5 minutes to DR; RTO 1 hour |
| Backup methods | Different on almost every server | One service, immutable copies, restore tested monthly |
Licence and cost figures are design targets, not a licensing opinion. They depend on the contracts, discounts and support terms in place, and are confirmed with your licensing team and the vendor before any change is made.
What a team needs to deliver this
Oracle licence assessment
Building a licence baseline from servers, editions, options and contracts, and modelling consolidation against it.
Oracle consolidation
Dedicated estates, container databases, Data Guard and resource management for shared servers.
PostgreSQL platforms
Patroni HA, connection pooling, backup with pgBackRest and running PostgreSQL at production scale.
Database migration
Schema conversion, PL/SQL rewrites and change data capture for low-downtime cut-overs.
HA and DR design
Recovery tiers, standby databases and failover tests that the business signs off.
Regulated data platforms
Encryption, key management and audit for insurance and financial data.
Other scenarios
Public cloud to private cloud
A B2B SaaS company moves its steady workloads off public cloud to a private cloud, and keeps burst capacity where it is cheap.
Read →Hybrid cloudHybrid cloud for omnichannel retail
An omnichannel retailer keeps ERP and stores on-premises and bursts its online storefront to public cloud for 10x sale-day traffic.
Read →Data centre consolidationThree data centres into one
A manufacturing group folds three ageing data centres from past acquisitions into one modern primary site and a DR site.
Read →Paying for database cores that sit idle most of the day?
Send us a list of your Oracle servers and databases and what each one runs. We will come back with a plain first view of what could consolidate, what could move to PostgreSQL and roughly how the licence position would change.