- BFSIBanking, Financial Services & Insurance
- HealthcareComing soon
- ManufacturingComing soon
- Retail & E-CommerceComing soon
The licence you are quoted is for the database. The cost you will carry is the migration — and nobody quotes that.
Engine licensing is the visible number, and it is usually the smaller one. The application rewrite, the driver differences, the stored procedures and the testing are where the project actually spends — and none of it appears on a vendor quote.
The test: ask whoever estimated the migration whether they counted the schema or the application. Schema conversion is largely automatable. Application behaviour is not, and that is the half that overruns.
Already decided — What this page decides
Still yours to weigh
Four different jobs, all called “database tooling”.
Nineteen products doing four distinct jobs. Seven are the database — an engine you license and run. Six monitor one somebody else supplies. Five put schema changes through the pipeline the way application code already goes. One models the data for governance rather than operations.
They are routinely conflated in a requirement, and the cost of conflating them is specific: buying monitoring when the problem was deployment friction, or buying an engine subscription when the actual gap was that nobody can see which query is slow.
The row to get exactly right
The licence unit. Per core, per instance, per developer or consumption — and per core on virtualised infrastructure is where estates get counted for hosts their database never used. Get the virtualisation counting policy in writing before signing anything per-core; it is the single most common surprise in this route.
Often confused withObservability & APM — why the request was slow, from outside →·Developer Tools — the pipeline the schema change ships through →·Backup & Recovery — protecting the data, estate-wide →
Four terms, resolved
These are not tiers. A tool that monitors a database perfectly will not migrate it, and a migration path says nothing about whether the result is healthy.
Database monitoring vs APM
The query was slow, or the plan changed?
Managed vs self-hosted vs DBaaS
Where does the support boundary sit?
Migration vs replication
Different engine, or another copy of the same one?
Compatibility vs conversion
How much application code survives?
Six things decide this purchase. The feature grid is none of them.
Seven variables move the shortlist.
Engine and version coverage
Postgres, SQL Server, Oracle, MongoDB, MySQL — and what 'supported' means per tool, which varies from full diagnostics to a connection test.
The support boundary
Self-managed, managed subscription on your infrastructure, or DBaaS. This decides the vendor list before any feature does.
Migration tooling and realistic effort
Especially Oracle-to-Postgres, which is the live movement in Indian enterprises. Estimate from the application, not the schema.
Monitoring depth versus APM overlap
Both name a slow query. Only one explains the plan. Decide whether you are buying both deliberately.
Licence model
Per core, per instance, per developer; subscription or perpetual. Per core on virtualised hosts is the one to get in writing.
Compliance and audit reporting
Whether the tool produces evidence an auditor accepts, or a screenshot somebody has to interpret.
India support presence and hours
Undocumented across every vendor here. A support contract that does not cover Indian business hours is a real operational cost.
Narrow 19 products to your shortlist
Pick the engines you run and the job you need done. Products drop out with the reason stated, never silently.
What you need it to do
The engines you actually run
How it has to run
India
Indian region and support-hours coverage are annotated rather than used to eliminate: they are undocumented across every vendor here, so the product is flagged for you to confirm.
quoted per core, subscription; Oracle-compatible Postgres — PL/SQL, Oracle syntax and package compatibility so a migration changes far less application code than plain Postgres would
Enterprises with a live Oracle renewal and budget released to move off it — the most-proven compatibility path, and the one that keeps the most stored procedures intact.
The catch: Compatibility reduces the rewrite; it does not remove it. The estimate that matters is the application's, not the schema's — and per-core licensing on virtualised infrastructure counts hosts in ways that surprise people. Confirm what the vendor counts.
quoted per core; enterprise-hardened Postgres without the Oracle compatibility layer — for estates already on Postgres that need enterprise support, security and extended capability
Estates already standardised on Postgres that want a supported enterprise distribution rather than community builds.
The catch: No Oracle compatibility layer, so it is the wrong SKU for a migration project — that is Advanced Server. Buying this expecting PL/SQL support is the most common mix-up in the EDB line.
quoted per core as an addition to the Postgres subscription; active-active distributed replication for near-continuous availability across sites
Estates whose Postgres cannot take a maintenance window — multi-site, active-active, with failover measured in seconds.
The catch: Active-active is an architecture decision, not a switch: conflict handling and application behaviour must be designed for it. It also adds licensed cores rather than replacing them.
quoted; the multi-model platform bringing analytics and AI workloads onto the same Postgres estate rather than exporting to a separate system
Postgres estates that want vector and analytical workloads beside the transactional data instead of a second platform to move it to.
The catch: Newer than the core server line and the strongest case assumes EDB Postgres underneath. If the requirement is a dedicated vector database, a purpose-built one is deeper.
consumption-priced per cluster on compute, storage and data transfer, with Indian cloud regions available; the vendor runs the database and the support boundary is the endpoint
Teams that want the document model without operating it — and who would rather the scaling decisions be a slider than a project.
The catch: Consumption pricing is honest and hard to forecast: an inefficient query pattern shows up as a bill rather than a slow dashboard. Egress and cross-region transfer are billed separately.
quoted for the Enterprise Advanced subscription; the same document database run on your own infrastructure, with the operational burden and the residency control both yours
Estates that must keep the data on their own infrastructure, for residency, latency or policy reasons.
The catch: You own the upgrades, the backups, the sharding decisions and the on-call. The Atlas features arrive later, and some do not arrive at all.
metered within Atlas consumption; vector storage and search beside the operational documents, so retrieval-augmented applications query one database rather than syncing two
Teams building AI retrieval features that already store the source documents in MongoDB — one database, no synchronisation job.
The catch: Tied to Atlas: the self-managed database is not the path here. A dedicated vector database will be deeper on index tuning and scale.
quoted per monitored instance; estate-wide database health — waits, blocking, disk, backups and alerting across SQL Server, Postgres and Oracle from one console
DBA teams responsible for many instances who need one place to see which of them is unhealthy right now.
The catch: Instance-metered, so a sprawling estate of small databases costs like a large one. It watches the database and does not trace the application request that caused the load.
quoted per developer; schema migrations under version control so database changes ship through the same pipeline as application code, with a documented rollback path
Teams whose deployments stall because the schema change is a manual step performed by one person at the weekend.
The catch: Per developer, so it scales with the team rather than the estate. It versions the schema; it does not tell you the production database is unhealthy.
quoted per developer; provisioning realistic test databases with sensitive fields masked, so non-production environments stop being a copy of production data
Regulated estates where a production restore into a test environment is the quiet compliance problem nobody has raised yet.
The catch: Masking rules are yours to define and maintain, and they drift as the schema changes. It is a discipline with a tool, not a tool that supplies the discipline.
quoted per developer; the SQL Server developer bundle — compare, data compare, prompt, source control and unit testing in one licence
SQL Server shops whose developers work in SSMS all day and lose time to manual comparison and deployment scripting.
The catch: SQL Server only. On a mixed estate it covers one engine and Flyway covers the rest, which is two licences for one job.
quoted per monitored instance, perpetual or subscription; SQL Server performance monitoring with query-level diagnostics, blocking analysis and predictive alerting
SQL Server estates that want deep engine-level diagnostics on their own infrastructure without a SaaS telemetry pipeline.
The catch: SQL Server only and on-premises oriented. It is a specialist, so a mixed-engine estate needs a second tool beside it.
quoted per developer; cross-platform DBA and development tooling — administration, development, tuning and space management across four engines from one interface
DBA teams running a genuinely mixed estate who would rather learn one tool than four vendor consoles.
The catch: Breadth over depth: it is not as deep on any single engine as that engine's specialist. Interface age shows against newer tools.
quoted per named user; enterprise data modelling — logical and physical models, lineage and a business glossary over a multi-engine estate
Organisations that need the data model documented and governed rather than inferred from whatever is in production.
The catch: Modelling and governance, not operations: it will not tell you the database is slow. Its value depends on someone owning the models, which is a role rather than a licence.
quoted per instance; compressed, encrypted SQL Server backups with faster restores and policy-based scheduling across the estate
SQL Server estates whose backup window has stopped fitting the night, or whose restore time is the number that fails an audit.
The catch: SQL Server only and focused on the database layer — see the Backup & Cyber Resilience guides for the estate-wide picture including immutability.
quoted per monitored instance; cross-platform database observability with workload analytics across the widest engine list here — SQL Server, Oracle, Postgres, MySQL, MongoDB and more
Genuinely mixed estates that need one console across every engine rather than a specialist tool per database.
The catch: Breadth means the per-engine depth is behind the single-engine specialists, and the console is dense. It is a platform decision, not a quick install.
quoted per monitored instance; SQL Server-specific performance monitoring with wait-state analysis and change tracking on the engine
SQL Server estates wanting Quest depth on one engine without the cross-platform console.
The catch: Single engine, and on a mixed estate you end up buying the cross-platform edition anyway. Compare the two before signing.
quoted per monitored instance; Oracle performance monitoring with wait-event analysis, RAC awareness and storage correlation
Oracle estates — including those planning an exit, where knowing which workloads are genuinely heavy shapes the migration order.
The catch: Oracle only. If the plan is to leave Oracle, this is a tool for the journey rather than the destination.
quoted per instance as an addition to Foglight; query-level diagnostics with historical plan comparison — the layer that answers why the plan changed, not merely that it did
Estates whose recurring incident is 'the same query got slow overnight' and nobody can prove what changed.
The catch: An add-on rather than a standalone product, so it assumes Foglight underneath and adds to that bill.
Why each constraint rules out what it doesShow the reasoning ↓
the database itselfRules out Redgate Monitor, Redgate Flyway, Redgate Test Data Manager, Redgate SQL Toolbelt, Idera SQL Diagnostic Manager, Idera DB PowerStudio, Idera ER/Studio, Idera SQL Safe Backup, Quest Foglight for Databases, Quest Foglight for SQL Server, Quest Foglight for Oracle and Quest Foglight Performance Investigator — a tool that works on a database somebody else supplies. That leaves EDB Postgres Advanced Server, EDB Postgres Extended Server, EDB Distributed High Availability, EDB Postgres AI, MongoDB Atlas, MongoDB Database (self-managed) and MongoDB Atlas Vector Search.
database monitoringRules out EDB Postgres Advanced Server, EDB Postgres Extended Server, EDB Distributed High Availability, EDB Postgres AI, MongoDB Atlas, MongoDB Database (self-managed), MongoDB Atlas Vector Search, Redgate Flyway, Redgate Test Data Manager, Redgate SQL Toolbelt, Idera DB PowerStudio, Idera ER/Studio and Idera SQL Safe Backup — not a monitoring product. That leaves Redgate Monitor, Idera SQL Diagnostic Manager, Quest Foglight for Databases, Quest Foglight for SQL Server, Quest Foglight for Oracle and Quest Foglight Performance Investigator.
database DevOpsRules out EDB Postgres Advanced Server, EDB Postgres Extended Server, EDB Distributed High Availability, EDB Postgres AI, MongoDB Atlas, MongoDB Database (self-managed), MongoDB Atlas Vector Search, Redgate Monitor, Idera SQL Diagnostic Manager, Idera ER/Studio, Quest Foglight for Databases, Quest Foglight for SQL Server, Quest Foglight for Oracle and Quest Foglight Performance Investigator — not database DevOps tooling. That leaves Redgate Flyway, Redgate Test Data Manager, Redgate SQL Toolbelt, Idera DB PowerStudio and Idera SQL Safe Backup.
migration toolingRules out EDB Postgres Extended Server, EDB Postgres AI, MongoDB Atlas, MongoDB Database (self-managed), Redgate Flyway, Idera DB PowerStudio and Idera ER/Studio — some import tooling, but no documented engine-migration path; EDB Distributed High Availability, MongoDB Atlas Vector Search, Redgate Monitor, Redgate Test Data Manager, Redgate SQL Toolbelt, Idera SQL Diagnostic Manager, Idera SQL Safe Backup, Quest Foglight for Databases, Quest Foglight for SQL Server, Quest Foglight for Oracle and Quest Foglight Performance Investigator — no migration tooling. That leaves EDB Postgres Advanced Server.
PostgresRules out MongoDB Atlas, MongoDB Database (self-managed), MongoDB Atlas Vector Search, Redgate SQL Toolbelt, Idera SQL Diagnostic Manager, Idera SQL Safe Backup, Quest Foglight for SQL Server and Quest Foglight for Oracle — Postgres is not a covered engine. That leaves EDB Postgres Advanced Server, EDB Postgres Extended Server, EDB Distributed High Availability, EDB Postgres AI, Redgate Monitor, Redgate Flyway, Redgate Test Data Manager, Idera DB PowerStudio, Idera ER/Studio, Quest Foglight for Databases and Quest Foglight Performance Investigator.
SQL ServerRules out EDB Postgres Advanced Server, EDB Postgres Extended Server, EDB Distributed High Availability, EDB Postgres AI, MongoDB Atlas, MongoDB Database (self-managed), MongoDB Atlas Vector Search and Quest Foglight for Oracle — SQL Server is not covered. That leaves Redgate Monitor, Redgate Flyway, Redgate Test Data Manager, Redgate SQL Toolbelt, Idera SQL Diagnostic Manager, Idera DB PowerStudio, Idera ER/Studio, Idera SQL Safe Backup, Quest Foglight for Databases, Quest Foglight for SQL Server and Quest Foglight Performance Investigator.
OracleRules out EDB Postgres Extended Server, EDB Distributed High Availability, EDB Postgres AI, MongoDB Atlas, MongoDB Database (self-managed), MongoDB Atlas Vector Search, Redgate SQL Toolbelt, Idera SQL Diagnostic Manager, Idera SQL Safe Backup and Quest Foglight for SQL Server — Oracle is not covered. That leaves EDB Postgres Advanced Server, Redgate Monitor, Redgate Flyway, Redgate Test Data Manager, Idera DB PowerStudio, Idera ER/Studio, Quest Foglight for Databases, Quest Foglight for Oracle and Quest Foglight Performance Investigator.
MongoDBRules out EDB Postgres Advanced Server, EDB Postgres Extended Server, EDB Distributed High Availability, EDB Postgres AI, Redgate Monitor, Redgate Flyway, Redgate Test Data Manager, Redgate SQL Toolbelt, Idera SQL Diagnostic Manager, Idera DB PowerStudio, Idera SQL Safe Backup, Quest Foglight for SQL Server, Quest Foglight for Oracle and Quest Foglight Performance Investigator — MongoDB is not covered. That leaves MongoDB Atlas, MongoDB Database (self-managed), MongoDB Atlas Vector Search, Idera ER/Studio and Quest Foglight for Databases.
a managed serviceRules out EDB Distributed High Availability, MongoDB Database (self-managed), Redgate Monitor, Redgate Flyway, Redgate Test Data Manager, Redgate SQL Toolbelt, Idera SQL Diagnostic Manager, Idera DB PowerStudio, Idera ER/Studio, Idera SQL Safe Backup, Quest Foglight for Databases, Quest Foglight for SQL Server, Quest Foglight for Oracle and Quest Foglight Performance Investigator — no managed service: the operational burden is yours. That leaves EDB Postgres Advanced Server, EDB Postgres Extended Server, EDB Postgres AI, MongoDB Atlas and MongoDB Atlas Vector Search.
on-premisesRules out MongoDB Atlas and MongoDB Atlas Vector Search — managed service only. That leaves EDB Postgres Advanced Server, EDB Postgres Extended Server, EDB Distributed High Availability, EDB Postgres AI, MongoDB Database (self-managed), Redgate Monitor, Redgate Flyway, Redgate Test Data Manager, Redgate SQL Toolbelt, Idera SQL Diagnostic Manager, Idera DB PowerStudio, Idera ER/Studio, Idera SQL Safe Backup, Quest Foglight for Databases, Quest Foglight for SQL Server, Quest Foglight for Oracle and Quest Foglight Performance Investigator.
not per-coreRules out EDB Postgres Advanced Server, EDB Postgres Extended Server and EDB Distributed High Availability — per-core licensing, which on virtualised infrastructure counts hosts in ways that surprise people. That leaves EDB Postgres AI, MongoDB Atlas, MongoDB Database (self-managed), MongoDB Atlas Vector Search, Redgate Monitor, Redgate Flyway, Redgate Test Data Manager, Redgate SQL Toolbelt, Idera SQL Diagnostic Manager, Idera DB PowerStudio, Idera ER/Studio, Idera SQL Safe Backup, Quest Foglight for Databases, Quest Foglight for SQL Server, Quest Foglight for Oracle and Quest Foglight Performance Investigator.
an Indian regionRules nothing out on published terms. It flags EDB Postgres Advanced Server — An Indian region or in-country support hours are not documented on the vendor's pages, EDB Postgres Extended Server — An Indian region or in-country support hours are not documented on the vendor's pages, EDB Distributed High Availability — An Indian region or in-country support hours are not documented on the vendor's pages, EDB Postgres AI — An Indian region or in-country support hours are not documented on the vendor's pages, MongoDB Database (self-managed) — An Indian region or in-country support hours are not documented on the vendor's pages, Redgate Monitor — An Indian region or in-country support hours are not documented on the vendor's pages, Redgate Flyway — An Indian region or in-country support hours are not documented on the vendor's pages, Redgate Test Data Manager — An Indian region or in-country support hours are not documented on the vendor's pages, Redgate SQL Toolbelt — An Indian region or in-country support hours are not documented on the vendor's pages, Idera SQL Diagnostic Manager — An Indian region or in-country support hours are not documented on the vendor's pages, Idera DB PowerStudio — An Indian region or in-country support hours are not documented on the vendor's pages, Idera ER/Studio — An Indian region or in-country support hours are not documented on the vendor's pages, Idera SQL Safe Backup — An Indian region or in-country support hours are not documented on the vendor's pages, Quest Foglight for Databases — An Indian region or in-country support hours are not documented on the vendor's pages, Quest Foglight for SQL Server — An Indian region or in-country support hours are not documented on the vendor's pages, Quest Foglight for Oracle — An Indian region or in-country support hours are not documented on the vendor's pages and Quest Foglight Performance Investigator — An Indian region or in-country support hours are not documented on the vendor's pages — marked on the cards, not removed.
Per core is the licensing trapOn virtualised infrastructure, per-core counting frequently includes cores your database never uses — the host's, not the VM's. Confirm in writing what the vendor counts before signing anything per-core, and get the virtualisation policy in the contract.
Migration is estimated from the wrong artefactTeams estimate an Oracle-to-Postgres move from the schema, because the schema is easy to count. The cost lives in the application: stored procedures, driver behaviour, SQL dialect, transaction assumptions. EDB's compatibility layer reduces that work materially; it does not remove it.
Monitoring gets bought twiceAPM names the slow query from the outside; database monitoring explains it from inside the engine. Estates commonly own both without deciding to. That is defensible — but decide it, rather than discovering it at renewal.
Open source is not free at the support boundaryPostgres, MySQL and MongoDB community editions cost nothing to download. The number that appears later is the support contract, and it appears at the worst possible moment. Budget it at the start.
Eight situations, and what each one buys
If one of these is your sentence, the shortlist is short.
An Oracle renewal arrived and somebody said Postgres
Why: Advanced Server is the most-proven compatibility path; Foglight for Oracle tells you which workloads are heavy, which decides the migration order.
The trade-off: Compatibility reduces the rewrite rather than removing it — read the depth section below before committing to a date.
We run four different engines and four different consoles
Why: Both cover a genuinely mixed estate from one place — Foglight for monitoring, PowerStudio for administration.
The trade-off: Breadth trades against per-engine depth; the specialists see more on any single engine.
Schema changes are a manual step someone does at the weekend
Why: Migrations under version control, shipping through the same pipeline as application code, with a documented rollback.
The trade-off: Per developer, so it scales with team size. Toolbelt is SQL Server only; Flyway spans engines.
We do not want to run a database at all
Why: The vendor owns upgrades, backups and scaling; you get an endpoint and a support boundary.
The trade-off: Consumption pricing is honest and hard to forecast — an inefficient query becomes a bill rather than a slow dashboard.
The data cannot leave our infrastructure
Why: All three run entirely on your own infrastructure with a commercial support contract behind them.
The trade-off: You own the upgrades and the on-call — the operational burden the managed price was covering.
The same query got slow overnight and nothing changed
Why: Historical plan comparison is the only thing that proves what changed — usually statistics or an index, not the code.
The trade-off: Performance Investigator is an add-on and assumes Foglight underneath.
Our test environment is a copy of production, including the personal data
Why: Provisioning realistic test databases with sensitive fields masked, which is the quiet compliance problem in most estates.
The trade-off: Masking rules are yours to define and they drift as the schema changes.
We are building retrieval features on our own documents
Why: Vectors beside the operational data means one database and no synchronisation job between two systems.
The trade-off: Both assume their platform underneath, and a dedicated vector database will be deeper on index tuning at scale.
This is a real, current, budget-released movement rather than a theoretical option. An Oracle renewal arrives, the number is larger than last time, and somebody senior asks what Postgres would cost. The honest answer has three parts, and most vendors only give the first.
The licence saving is real. Postgres — community or enterprise-supported — costs a fraction of Oracle for equivalent workloads. That part of the business case survives scrutiny.
The schema converts more easily than the application. Tables, indexes and constraints are largely automatable. What does not convert cleanly: PL/SQL packages, Oracle-specific SQL, driver behaviour, sequence and transaction semantics, and every place the application assumed Oracle. Estimating from the schema is the standard mistake, and it is why these projects overrun.
Compatibility changes the size of that second problem. EDB Postgres Advanced Server accepts PL/SQL and Oracle syntax, so a large share of stored procedures and application SQL runs unchanged. That is its distinctive strength and the entire commercial case for it over community Postgres. It is measured in developer-months saved, not in licence.
Assess before committing to a date. EDB documents an assessment step that identifies which workloads move cleanly and which need attention — and a migration plan built on that assessment is the difference between a project and an incident.
Before you commit to a date
- How many PL/SQL packages, and how many lines — counted, not estimated?
- Which applications talk to this database, including the ones nobody maintains?
- Who regression-tests it, and against what — is there a test suite at all?
- What is the rollback if cutover fails, and has it been rehearsed?
- Does the assessment cover the application, or only the schema?
Migration effort estimates on this page come from vendor documentation. Realistic timelines for your estate are a delivery-team conversation, not a datasheet number.
What changes as the estate grows
Database tooling scales by instance count and engine variety, not by user count.
A handful of instances, one engine
- —Native tooling plus a specialist is enough
- —Per-instance pricing is affordable at this size
- —Schema changes can still be manual, just about
Put this in your PoC
Version the schema before the team grows, not after.
Dozens of instances, one or two engines
- —Estate-wide monitoring starts to pay
- —Per-instance costs become visible
- —Test data and masking become a real question
Put this in your PoC
Count instances honestly — sprawl is what moves this bill.
Mixed engines at scale
- —Cross-platform consoles beat four specialists
- —Licence models differ per engine and complicate renewal
- —Modelling and lineage start to matter
Put this in your PoC
Compare the cross-platform edition against the specialists you already own.
Enterprise, with a migration in flight
- —Per-core counting on virtualised hosts becomes material
- —Monitoring both old and new engines through the transition
- —Support hours and escalation paths become contractual
Put this in your PoC
Get the virtualisation counting policy in the contract, in writing.
Where a vendor does not publish list pricing, this page says so rather than implying a figure.
Getting out
The database is the hardest thing on this site to leave, and the tooling around it is not.
The data
Every engine exports; the format and the downtime are the negotiation
Stored procedures and dialect SQL
Rewritten unless the target offers a compatibility layer
Monitoring configuration
Thresholds, baselines and alert routing are re-authored per tool
Schema version history
Flyway and similar keep migrations in your repository, not the vendor's
The practical consequence: version your schema migrations in your own repository from day one. It is the one artefact here that stays yours whatever you buy next.
What it costs
By licence unit, in USD and INR, with the counting policy named.
Do you already own one?
Four checks, in the order most likely to return a yes.
- Your cloud provider
- RDS, Azure SQL and Cloud SQL include basic monitoring Enough for health and simple alerting; they stop at wait-state and plan-level diagnosis.
- Native engine tooling
- Query Store, pg_stat_statements and AWR are already there Genuinely useful and free, and they need somebody who knows how to read them.
- Your APM
- It already names the slow query Different depth, same symptom. See the boundary section before buying database monitoring as well.
- Community editions
- Postgres, MySQL and MongoDB cost nothing to download The support contract is the number that appears later. Budget it at the start, not at the incident.
Native tooling is stronger in this category than most buyers assume. The case for a commercial tool is usually estate-wide visibility, not depth on one instance.
What the rest actually cost
Four licence units, and where each one surprises people.
TechBag quotes every one of these in INR with GST, and models your actual volumes against each meter rather than comparing rates. Where a vendor publishes no list price, this page says so instead of repeating a third-party figure.
TechBag gives INR pricing, GST, PO cycle, minimums and tier-matched quotes. The INR above is conversion for scale at ≈₹83/$; the tier-matched INR quote is ours.
What isn’t in the licence price
Migration effort
The largest line in any engine change, and it never appears on the vendor quote. Estimate from the application.
Support contracts on open source
Community editions are free to download. Production support is not, and it is needed at the worst moment.
Per-core counting on virtual hosts
Cores your database never used, counted because the hypervisor could have scheduled them there.
The DBA who reads the output
Every monitoring tool here produces more signal than an unowned console will ever action.
What goes wrong
Five ways this purchase goes wrong.
Per-core licensing counted against the host, not the VM
The estate is billed for cores the database never used. Get the virtualisation counting policy in the contract before signing.
Migration estimated from the schema
Tables convert; PL/SQL, driver behaviour and application assumptions do not. The schema is the easy half and the cheap half.
Monitoring bought twice
Once inside APM and once at the database layer. Defensible if deliberate — expensive when discovered at renewal.
Support hours that miss Indian business hours
A severity-one at 10am IST answered at 9am Pacific is a working day lost. Confirm coverage, not just the SLA number.
Open source assumed free, then the support contract arrives
Usually mid-incident, at a price nobody budgeted. Decide the support position before production, not during it.
Three doors — pick by where you are
Vendor-neutral. No gated content. · Last reviewed