Managed database vs self-hosted is not mainly a question of where PostgreSQL or MySQL runs. It is a decision about who owns production database operations: patching, backups, recovery tooling, monitoring, failover, storage growth, upgrades, and incident response.
For most small product teams, a managed database is the safer default when the service supports the required engine features. Self-hosting becomes the better choice when you have a documented requirement for operating-system access, unsupported extensions, custom topology, exact version control, or another capability the managed service cannot provide.
Raff Technologies supports both models: teams can use a managed database when they want to reduce operational ownership, or run their own database on a Raff VM when deeper control is more important. The right decision depends on total operating cost, recovery requirements, control, and who will own incidents at 3 a.m.
Managed database vs self-hosted: quick verdict
| Question | Managed database | Self-hosted database |
|---|---|---|
| Who patches the database platform? | Provider within service policy | Your team |
| Who manages the OS? | Provider | Your team |
| Who provides backup tooling? | Provider within plan scope | Your team |
| Who validates recovery? | Shared responsibility | Your team |
| Who designs schemas and indexes? | Your team | Your team |
| Root / OS access | Usually no | Yes |
| Unsupported extensions/custom binaries | Often restricted | Usually possible |
| High availability | Often available as a service feature | You design and operate it |
| Monitoring platform | Usually included to a defined scope | You build/integrate it |
| Operational flexibility | Lower | Higher |
| Operational burden | Lower | Higher |
| Best fit | Teams prioritizing product velocity and operational simplicity | Teams with hard control requirements and database operations capability |
The most important point: managed does not mean “no database work.” It means the provider owns more of the infrastructure and service lifecycle while your team still owns the data model, queries, indexes, migrations, credentials, connection behavior, and application correctness.
What does a managed database actually manage?
A managed database service usually takes responsibility for more of the database platform layer.
Depending on the provider and plan, that can include:
- database installation;
- operating-system maintenance;
- database patching and maintenance workflows;
- automated backup infrastructure;
- point-in-time recovery tooling;
- storage management;
- metrics and service monitoring;
- replication or high-availability options;
- service-level failover tooling;
- private-network integration;
- controlled version upgrades.
The exact boundary matters. “Managed” is not a universal specification.
Before buying any managed database, ask:
- What exactly is backed up?
- How long are backups retained?
- Is point-in-time recovery available?
- Who initiates restore operations?
- What is the expected failover behavior?
- Are maintenance windows configurable?
- Which extensions and versions are supported?
- How are storage and connections scaled?
- Is private networking available?
- What happens if you need to migrate away?
Those answers are more useful than the label “fully managed.”
What remains your responsibility with a managed database?
Managed services remove platform work, not application responsibility.
Your team still owns:
- schema design;
- migrations;
- indexes;
- query performance;
- transaction behavior;
- connection pooling;
- user and application credentials;
- least-privilege access;
- data retention decisions;
- capacity planning;
- application behavior during failover;
- validating that restored data is actually usable.
A managed provider cannot know whether yesterday’s restore point contains a business-level error, whether a migration should be rolled back, or whether an index matches your application access pattern.
This is why a good managed database reduces operational burden without pretending the database operates itself.
What self-hosting really means in production
Self-hosting gives you more control because your team owns more of the stack.
That usually means responsibility for:
VM or bare-metal provisioning + OS hardening + database installation + version selection + patching + TLS + firewall rules + monitoring + alerts + backups + restore tests + storage growth + replication + failover + upgrades + incident response + decommissioning
Installing PostgreSQL or MySQL can take minutes. Operating it safely for years is the actual cost of self-hosting.
Self-hosting is justified when the extra control solves a real requirement. Examples include:
- root access is required;
- a specific extension is unsupported by the managed service;
- exact database binaries or patch timing are required;
- custom authentication modules are needed;
- the application depends on filesystem-level access;
- the team needs a custom replication or clustering topology;
- superuser operations restricted by the managed provider are required;
- a compliance or architectural requirement demands deeper infrastructure ownership.
“We prefer control” is not enough by itself. Every additional control creates an operational obligation.
Managed database cost vs self-hosted cost
This is where many comparisons become misleading.
A self-hosted database can have a lower infrastructure invoice and still have a higher total operating cost.
A fair self-hosted cost model includes:
Primary VM + standby/replica capacity + storage + backup storage + monitoring + networking + engineering time + on-call response + patching + upgrades + restore testing + incident recovery
A managed database cost model includes:
Managed database plan + optional HA/replicas + storage growth + backup retention beyond included limits + networking/transfer where applicable + engineering time for schema, queries, and migrations
The comparison must use the same reliability target.
Comparing one self-hosted VM with a managed HA database is not a fair price comparison. One gives you a single database server; the other may include backup automation, monitoring, replicas, failover, and a managed maintenance path.
Likewise, if your self-hosted team already has mature automation, monitoring, backup tooling, and on-call coverage, self-hosting may be economically efficient.
The hidden cost is operator time
The biggest small-team cost is often not CPU or storage. It is engineering attention.
Consider a database that needs only two hours of routine operational work per month. That sounds small until the work includes:
- checking backup failures;
- reviewing storage growth;
- patch planning;
- security updates;
- failed replica investigation;
- connection saturation;
- restore testing;
- upgrade preparation.
Then add one production incident.
If the person handling those tasks is also responsible for shipping product features, database operations compete directly with revenue-generating engineering work.
This is why managed database services are often worth the premium for small teams even when the raw VM cost is lower.
Recovery should decide the architecture before price does
The most important production questions are:
- How much data can you afford to lose?
- How long can the application be unavailable?
Those become your RPO and RTO targets.
Define:
- backup frequency;
- retention;
- point-in-time recovery requirements;
- restore procedure;
- restore owner;
- expected restore duration;
- application validation after recovery;
- the date and result of the last restore test.
Backups that have never been restored are assumptions, not proven recovery plans.
A managed service can provide backup and PITR tooling, but your team still needs to decide which restore point is safe and verify that the application works afterward.
A self-hosted team owns both the database and the recovery platform. That includes engine-aware backups, storage, retention, encryption, automation, monitoring, and restore testing.
VM snapshots can be useful, but they should not automatically be treated as database-consistent backups without a tested procedure.
High availability is not the same as backup
Replication and high availability reduce downtime from certain failures.
They do not protect you from every data-loss scenario.
For example, a destructive application query can be replicated to the standby immediately.
So production architecture often needs both:
High availability + independent backups / PITR
Managed services can make this easier because HA, backups, monitoring, and failover can be integrated into one platform.
Self-hosting can provide the same outcomes, but your team must design, operate, test, and document them.
Scaling: managed is easier only when the bottleneck is understood
Managed databases can simplify resizing, storage expansion, replicas, and connection-management options.
But a larger database does not fix every problem.
Before scaling, identify whether pressure comes from:
- inefficient queries;
- missing indexes;
- too many connections;
- memory pressure;
- storage latency;
- lock contention;
- replication lag;
- write amplification;
- long-running transactions;
- application retry storms.
Connection capacity deserves special attention.
A useful estimate is:
application instances × pool size + workers/jobs + admin connections + monitoring + recovery headroom
A database can have available CPU and still reject traffic because the connection limit has been exhausted.
Managed database services reduce the infrastructure work around scaling. They do not remove the need to understand workload behavior.
Security responsibilities differ materially
In both models, your team owns:
- application credentials;
- secret storage;
- least privilege;
- database users and roles;
- destructive-operation controls;
- data classification;
- application vulnerabilities.
With self-hosting, your team additionally owns more of:
- OS patching;
- host hardening;
- database patching;
- firewall configuration;
- TLS deployment;
- backup security;
- vulnerability response;
- monitoring infrastructure.
Where possible, keep database traffic on private or tightly restricted network paths rather than exposing the database broadly to the public internet.
Portability and exit planning matter before purchase
Managed services can reduce operational work, but they can also introduce service-specific constraints.
Before choosing a provider, verify:
- supported engine versions;
- supported extensions;
- export methods;
- backup portability;
- migration tooling;
- network access;
- maintenance policy;
- upgrade policy;
- maximum storage/connection limits;
- how long a migration away would realistically take.
The safest managed architecture is one where you know how to leave before you need to.
Self-hosting usually gives more direct access to database files and configuration, but portability is not automatic there either. Custom clustering, filesystem layouts, and tooling can create their own migration complexity.
Managed PostgreSQL vs self-hosted PostgreSQL
PostgreSQL is a common case where the decision is less about the engine and more about operations.
Managed PostgreSQL usually fits when:
- supported extensions meet your needs;
- standard backup/PITR capabilities are enough;
- the team wants managed maintenance and monitoring;
- private connectivity and HA options fit the architecture;
- product engineering time matters more than host control.
Self-hosted PostgreSQL fits when:
- an unsupported extension is mandatory;
- OS-level tuning is required;
- custom replication/topology is needed;
- exact version/patch control matters;
- database operations are already a core internal capability.
For the PostgreSQL-specific decision, see Postgres Hosting: Managed vs Self-Hosted.
Managed MySQL vs self-hosted MySQL
The same framework applies to MySQL.
Managed MySQL can reduce work around maintenance, backups, monitoring, and availability when the service limits fit the application.
Self-hosting can make sense when the team needs deeper MySQL configuration, host access, custom plugins, or topology that the managed service does not support.
See MySQL Hosting: Managed vs Self-Hosted for the engine-specific decision.
How Raff supports both models
Raff provides two different paths because not every workload should be forced into the same operating model.
Raff Managed Databases
Raff Managed Databases is the path for teams that want the database platform operated as a managed service.
The value proposition is operational: reduce the amount of infrastructure work your application team must own around provisioning, maintenance, monitoring, backup/recovery tooling, networking, and availability features supported by the selected engine and plan.
Current engines, plan capabilities, limits, HA options, backup behavior, and free-tier eligibility can change independently of this guide, so use the live product page and console as the source of truth before production design.
Self-hosted database on Raff VM
A Raff VM is the path when your database needs deeper control.
You get a full-control VM, but the database remains self-managed. Your team owns installation, configuration, patching, monitoring, backups, restore testing, scaling, security, availability, and incident response inside the guest environment.
The architecture can be as simple as:
Application -> private/restricted connection Managed Database
or, when control is required:
Application VM -> private network Database VM -> customer-operated backups, monitoring, patching, HA and recovery
The second model is not worse. It simply transfers more responsibility to your team.
Which Raff path should you choose?
Choose Raff Managed Databases when:
- you do not need OS/root access;
- supported versions/extensions fit the application;
- your team wants less database-platform operations;
- managed backup/recovery and monitoring tooling are valuable;
- reducing on-call surface area matters;
- you want a simpler path from development to production.
Choose a self-hosted database on Raff VM when:
- you need root access;
- a required extension/plugin is unsupported;
- custom topology is necessary;
- you need exact database binary or patch control;
- you already have mature database automation and on-call ownership;
- a documented technical requirement justifies the additional operational burden.
If neither list is decisive, start with the managed model and document the blocker that would force you to self-host. That is usually safer than self-hosting first and discovering the operational cost later.
Production database buying checklist
Before paying for either model, write down:
- Engine and version required.
- Extensions/plugins required.
- Expected database size and monthly growth.
- Peak connections.
- Required RPO and RTO.
- Whether HA is required.
- Backup retention requirement.
- Private-network requirement.
- Compliance/security constraints.
- Who owns incidents and restores.
- Expected migration/exit path.
- Total monthly cost including operator time.
If you cannot answer these questions, the plan price alone is not enough information to choose a production database.