One estimate lists virtual machines and disks for a self-hosted database. Another includes a managed service with redundancy, support and automated operations. Comparing the totals is premature: these are different packages. Even using the same database engine does not make them equivalent.
Start with common requirements: workload, latency, recovery time, compatibility, access and support coverage. Then decide which work to retain internally. A lower resource price does not settle the choice, but the word managed does not prove a saving either.
Buy defined responsibilities, not freedom from problems
A managed service transfers some operational work to a provider. The boundary varies: who upgrades the engine, configures redundancy, retains backups and executes failover? Some capabilities are included; others require configuration or a different service tier. Check the actual offering.
The customer still owns its data, access model, application behaviour and acceptance of the outcome. Amazon RDS, for example, assigns query tuning to the customer in its responsibility model. Automated server maintenance will not fix a query that scans an entire table to retrieve one record.
Self-hosting does not require an owned data centre. A team can operate the database on rented machines: hardware remains the infrastructure provider's responsibility, while database installation and operations belong to the team. Map the actual duties rather than debating two labels.
Count engineering time without convenient extremes
Self-hosting includes recurring upgrades, backup checks, capacity planning and incident response, plus infrequent difficult operations. If one specialist holds all the knowledge, leave and staff turnover matter even when the salary is already budgeted.
But charging one small database for an entire team that already operates a shared platform is misleading too. Estimate additional workload, on-call coverage and product work displaced. Time freed for other work is different from a reduction in cash expenditure.
For the managed option, include storage, I/O, redundancy, transfer, support and required environments. Self-hosting may also need licences and paid external support. Compare normal demand, growth and recovery exercises, not just the cheapest initial deployment.
Who reconnects the application after a restore?
An automated backup does not complete the recovery journey. A provider may restore a separate instance, leaving the team to switch connections, check permissions and reconcile records. Creating a new instance is how RDS point-in-time recovery works.
An exercise must therefore reach a working application. Who selects the recovery point? How are operations completed after that point reconciled? Who authorises writes to resume? A button that starts restoration does not remove these decisions.
Also distinguish a support response target from a resolution time. A provider's availability terms do not automatically describe recovery of the entire product. The company still needs someone to coordinate support and restore the customer workflow.
Which freedom will the product actually use?
Self-hosting may be necessary for an extension, version, configuration or placement requirement the service cannot provide. That is a strong argument when the requirement exists in a real workflow. “We might someday need unrestricted access” is a much more expensive basis for deciding.
The reverse constraint matters too: the team must keep a self-managed installation updated. Freedom to postpone upgrades indefinitely is not a security advantage. For a managed service, inspect version support, compulsory changes and the ability to test them before production.
An exit plan needs an import test
For an important dependency, try a migration. Can the team export the data, load it into an acceptable alternative and execute the required operations? Do types, extensions, permissions and query behaviour remain usable? Downloading a file does not establish that another environment can run the product.
Estimate transfer time, permitted interruption and the transition period. An open-source engine can still be surrounded by provider-specific identity and operational tooling. A self-hosted installation also has dependencies: configuration, people and internal tools.
Record the choice alongside reasons to revisit it: a spending change, a new requirement or a change in staffing. Infrastructure need not follow one uniform model. Operating one specialised component internally while buying operations for others can be entirely reasonable, provided responsibility is explicit for each.