A managed database and a self-hosted database can run the same engine, but they place operational responsibility in different hands. With a managed service, the provider operates much of the database platform. With self-hosting, your team operates the database on a VM, dedicated server, or cluster it controls.
Choose a managed database when a small team needs reliable backups, monitoring, patching, scaling, and recovery without building a database-operations function. Choose self-hosting when the workload requires operating-system access, unsupported extensions, unusual replication, complete configuration control, or an ownership model the managed service cannot provide. Compare the exact responsibility boundary rather than assuming “managed” means no database work.
Managed and self-hosted databases assign responsibility differently
The database engine may be PostgreSQL, MySQL, Valkey, MongoDB, or another system in either model. The meaningful difference is who owns each operational layer.
| Responsibility | Managed database | Self-hosted database |
|---|---|---|
| Physical infrastructure | Provider | Infrastructure provider plus your team’s architecture choices |
| Operating system | Provider | Your team |
| Database installation | Provider | Your team |
| Minor patching | Usually provider-controlled | Your team |
| Major-version timing | Shared or guided process | Your team |
| Backup platform | Usually provider-operated | Your team designs and operates it |
| Restore request or workflow | Provider tooling plus customer decision | Your team |
| High-availability platform | Available according to service and plan | Your team designs, tests, and operates it |
| Monitoring platform | Usually included to a defined scope | Your team selects and integrates it |
| Schema and indexes | Your team | Your team |
| Queries and application behavior | Your team | Your team |
| Credentials and access policy | Shared responsibility | Your team |
| Data retention decisions | Your team within service capabilities | Your team |
| Cost and capacity planning | Your team | Your team |
A managed service reduces platform work. It does not take ownership of poor queries, unsafe migrations, missing indexes, accidental deletes, excessive connections, weak credentials, or an application that cannot tolerate failover.
Use eight questions to choose the operating model
Who is accountable when the database fails at night?
A self-hosted database needs a named responder who can diagnose disk exhaustion, memory pressure, replication lag, failed backups, corrupted configuration, certificate problems, operating-system issues, and database crashes.
A managed service moves part of that response to the provider, but the application team still needs to determine business impact, pause unsafe writes where necessary, validate restored data, and coordinate application recovery.
Choose managed when the honest answer is that no one on the team should own a database pager.
What recovery point and recovery time does the business require?
Recovery Point Objective, or RPO, defines how much data loss is acceptable. Recovery Time Objective, or RTO, defines how long recovery may take.
A nightly backup may be acceptable for an internal tool with an RPO near 24 hours. It is usually not acceptable for a transactional application that cannot lose a day of orders, messages, or account changes.
The database model must support:
- the required backup frequency;
- point-in-time recovery where necessary;
- retention long enough to discover delayed incidents;
- restore time at the expected data size;
- a tested application cutover after restore;
- off-site or failure-domain separation appropriate to the risk.
Choose from tested recovery behavior, not from a checkbox that says “backups included.”
Does the workload need operating-system or engine-level control?
Self-hosting is justified when the team must control:
- operating-system packages and kernel settings;
- filesystem layout;
- storage mount options;
- database binaries and exact patch timing;
- extensions unavailable in the managed catalog;
- custom background processes;
- unusual authentication modules;
- replication topology;
- superuser-level capabilities restricted by the provider;
- direct access to database files or logs.
Do not choose self-hosting merely because control feels safer. Every additional control becomes an operational responsibility.
Can the managed service support the required engine behavior?
Review the exact service rather than the generic category.
Confirm:
- supported database engines and versions;
- extension or plugin availability;
- connection limits;
- storage and scaling behavior;
- high-availability architecture;
- backup frequency and retention;
- point-in-time recovery granularity;
- restore destination and process;
- public and private connectivity;
- maintenance and upgrade policy;
- observability and log access;
- migration and export options.
A managed service that does not support a required extension, replication method, region, version, or access model is not the correct platform for that workload.
How much database expertise does the team already have?
Self-hosting is more reasonable when the team already has:
- database administration experience;
- infrastructure automation;
- monitoring and alerting standards;
- backup and restore runbooks;
- security hardening practices;
- patch and upgrade procedures;
- capacity and performance analysis skills;
- an on-call model.
Installing PostgreSQL or MySQL is not the difficult part. Keeping it recoverable, secure, observable, and maintainable over several years is the real workload.
How predictable is growth?
Growth affects CPU, memory, storage capacity, storage performance, connection count, write-ahead logs or binary logs, backup size, restore time, and replication lag.
Managed services often make plan changes and storage expansion easier, but the customer must still identify when the database is approaching a limit.
Self-hosting can offer more freedom in choosing compute and storage, but the team must plan expansions without corrupting data or creating long outages.
What does portability mean for this system?
Portability can mean several different things:
- standard client and wire-protocol compatibility;
- logical export and import;
- continuous replication to another environment;
- access to extensions used by the application;
- infrastructure-as-code recreation;
- freedom to choose a different provider;
- a tested exit plan within the required time.
A standard engine improves portability, but provider-specific extensions, authentication, networking, monitoring, and backup tooling can still create migration work.
What is the complete cost of ownership?
Do not compare only the managed monthly fee with the price of one VM.
The self-hosted model includes:
Compute and storage + backup storage and transfer + monitoring and alerting + standby or replica capacity + engineering time + on-call response + patching and upgrades + restore testing + spare capacity + incident risk
The managed model includes:
Database plan + optional HA or replicas + additional storage + backup retention outside the included level + data transfer where applicable + engineering time still required for schema and application work + provider and service constraints
The cheaper architecture is the one that meets the recovery and operating requirements at the lowest total cost, not necessarily the one with the lowest infrastructure line item.
Hard-stop conditions favor a managed database
A managed database is normally the safer default when several of these are true:
- The team has no database administrator or experienced database operator.
- No one can own 24/7 database incidents.
- Backups exist but restores are not regularly tested.
- Operating-system and database patching are frequently delayed.
- The product is early-stage and engineering time is better spent on application behavior.
- Standard engine versions and supported extensions are sufficient.
- The team needs a repeatable path to backups, monitoring, private connectivity, and optional high availability.
- The business needs clearer operational ownership from a provider.
A managed service does not eliminate risk, but it can remove work the team is unlikely to perform consistently.
Hard-stop conditions favor self-hosting
Self-hosting is normally justified when one or more requirements cannot be met by the managed platform:
- Root or operating-system access is required.
- The workload depends on unsupported extensions or plugins.
- A precise database version or patch schedule is mandatory.
- The team needs a custom replication, sharding, or clustering topology.
- Direct filesystem or database-file access is required.
- The managed service restricts a necessary administrative capability.
- Data must run in an environment the provider does not offer.
- A regulated or contractual control requires infrastructure ownership beyond the managed boundary.
- The team already operates a mature database platform at sufficient scale.
Document the requirement. “We want more control” is too vague to justify years of operational responsibility.
Backups and restores are the most important boundary
A database backup is valuable only when it can restore the required data within the required time.
For PostgreSQL, official documentation distinguishes SQL dumps, filesystem-level backups, and continuous archiving with point-in-time recovery. Different methods solve different recovery problems.
A complete recovery design defines:
- backup method;
- frequency;
- retention;
- encryption;
- storage location;
- failure-domain separation;
- integrity checks;
- restore procedure;
- restore environment;
- application validation;
- recovery owner;
- evidence from the last test.
Managed does not remove customer recovery decisions
The provider may schedule backups and expose a restore workflow. The customer still decides:
- how much history is needed;
- which point in time is safe;
- whether restoring in place is acceptable;
- how to validate data;
- how the application switches to the restored database;
- what happens to writes created during recovery;
- when the incident is considered resolved.
Self-hosted recovery needs independent automation
A snapshot of the VM or storage layer can be useful, but it should not be assumed to be an application-consistent database backup without a tested procedure.
Self-hosted teams should automate backups outside the database host, monitor completion, verify retention, and perform scheduled restores into a separate environment.
Replication is not a backup
Replication improves availability and can provide additional read capacity. It also copies many unwanted changes, including accidental deletes and destructive updates.
Use replicas and high availability for service continuity. Use backups and point-in-time recovery for historical recovery. Most production databases need both according to their risk profile.
High availability reduces some outages but adds systems to operate
High availability normally introduces more components:
- primary and standby or multi-node members;
- replication;
- health detection;
- failover logic;
- a stable client endpoint;
- split-brain prevention;
- recovery and rejoining procedures;
- monitoring for lag and degraded redundancy.
A managed service may operate much of this platform. The customer still needs to understand:
- whether failover is automatic;
- expected interruption;
- replication mode;
- data-loss behavior;
- endpoint behavior;
- whether the application reconnects correctly;
- what happens during maintenance;
- how the system returns to a protected state after failover.
A self-hosted team owns the entire topology and should rehearse node failure, promotion, client reconnection, and failed-node replacement.
Do not buy or build high availability without testing application behavior during failover.
Monitoring must cover both the database and its dependencies
PostgreSQL exposes cumulative statistics, active sessions, locks, replication state, I/O, background writers, checkpoints, and disk usage. Other engines expose equivalent operational data.
Monitor at least:
- availability and connection success;
- CPU and memory pressure;
- storage usage and growth rate;
- storage latency and throughput;
- connection count and pool saturation;
- slow and frequent queries;
- lock waits and deadlocks;
- replication lag;
- backup completion and age;
- restore-test age;
- cache hit behavior where relevant;
- error logs;
- certificate expiration;
- maintenance and version status.
The application view matters too. A healthy database process can still produce failed checkouts, timeouts, or incorrect results.
Managed platforms usually provide a baseline monitoring layer. Verify what is visible, how alerts are delivered, and whether raw metrics or logs can be exported.
Query and schema ownership stays with the application team
Managed database providers do not understand every application’s business logic.
The customer remains responsible for:
- schema design;
- indexes;
- query plans;
- data types and constraints;
- transaction boundaries;
- connection pooling behavior;
- migration safety;
- archival and retention policy;
- application-level authorization;
- avoiding unbounded queries;
- testing changes with realistic data.
A managed service can identify resource pressure or surface slow queries. It cannot automatically decide which index, query rewrite, or data-model change is correct for the product.
This is the central shared-responsibility rule:
The provider operates the database platform. The customer operates the data model and application behavior.
Security is shared in both models
Managed database security
The provider usually owns infrastructure and service hardening within the documented boundary. The customer still owns:
- credential issuance and rotation;
- least-privilege database roles;
- network allowlists or private connectivity choices;
- secret storage;
- application permissions;
- audit and retention requirements;
- data classification;
- destructive-operation controls;
- employee and service offboarding.
Self-hosted database security
The customer additionally owns:
- operating-system hardening;
- firewall configuration;
- package and database patching;
- TLS deployment and renewal;
- secure backups;
- log protection;
- host access;
- service isolation;
- vulnerability response.
In either model, keep the database off the public internet where the architecture supports private networking. When public access is required, use encrypted connections, narrow source restrictions, strong credentials, and monitoring.
Connection management can decide whether a database appears undersized
Application frameworks can open more database connections than expected, especially across many application instances, workers, jobs, and deployment environments.
Plan:
Maximum app instances × connection pool per instance + administrative and migration connections + monitoring connections + recovery headroom
A database can have idle CPU and still reject traffic because its connection limit is exhausted.
Managed services may include or support a connection pooler depending on the engine and plan. Self-hosted teams can deploy one, but then own its availability, configuration, credentials, and monitoring.
Connection pooling is not a substitute for fixing long transactions or queries that hold connections unnecessarily.
Scaling begins with diagnosis, not a larger plan
Before scaling, determine whether the pressure comes from:
- CPU-bound queries;
- insufficient memory for the working set;
- storage latency;
- storage capacity;
- connection count;
- lock contention;
- large sequential scans;
- write amplification;
- background maintenance;
- replication lag;
- application retry storms.
Vertical scaling can provide more CPU, memory, or storage performance. Read replicas can move some read traffic. Caching can reduce repeated work. Partitioning or sharding may help specific workloads but adds design complexity.
A managed service may make resizing or replicas easier. It does not remove the need to identify the bottleneck.
Self-hosting provides more tuning freedom, but that freedom should be exercised from measurements and load tests rather than copied configuration values.
Major upgrades require application planning in either model
Managed providers may automate minor updates and offer a guided major-version process. Self-hosted teams control timing but own every step.
A major upgrade can affect:
- extensions;
- drivers and ORMs;
- SQL behavior;
- authentication;
- replication;
- backup tooling;
- maintenance windows;
- performance plans;
- rollback feasibility.
Plan the upgrade with:
- compatibility review;
- representative staging data;
- application tests;
- backup and rollback evidence;
- extension validation;
- expected downtime or replication cutover;
- monitoring during and after change;
- a deadline before the old version becomes unsupported.
Control over timing is valuable only when the team actually keeps the database supported.
Portability needs a tested exit plan
Ask both managed and self-hosted operators:
- Can the database be exported logically?
- Can continuous replication reduce migration downtime?
- Are all required extensions available at the destination?
- How long would a full copy take at current data size?
- How are users, roles, secrets, and permissions recreated?
- What happens to sequences, jobs, large objects, and external integrations?
- Can the old and new systems run together during cutover?
- How is rollback handled after writes reach the new system?
Managed services can be portable when they expose standard protocols and migration paths. Self-hosting can still become difficult to move when it depends on custom infrastructure, undocumented tuning, local files, or operator knowledge.
Portability is a practiced process, not only an open-source engine name.
Small teams usually benefit from a stage-based model
Early product stage
A managed database is usually the safer default when:
- the product is still validating demand;
- the team is small;
- standard database capabilities are sufficient;
- downtime or data loss would distract the entire company;
- engineering time is the most constrained resource.
The goal is to avoid turning a database installation into a hidden operations project.
Growing production stage
Reassess:
- backup retention and restore time;
- high availability;
- read scaling;
- connection pooling;
- private networking;
- monitoring and slow-query visibility;
- storage growth;
- maintenance windows;
- provider limits;
- cost allocation.
A managed service often remains appropriate, but the plan and architecture may need to change.
Specialized or platform stage
Self-hosting becomes more defensible when the company has a platform or database team, a repeated requirement that managed services cannot meet, and enough scale to justify standardized internal operations.
At that point, do not create one-off database pets. Build repeatable provisioning, monitoring, backup, recovery, patching, access, and decommissioning workflows.
Hybrid models can separate production from experimentation
The decision does not need to apply identically to every database.
A team might use:
- managed PostgreSQL for production transactions;
- self-hosted disposable databases for local development or testing;
- managed Valkey for production caching;
- a self-hosted specialized engine for a workload unsupported by the managed catalog;
- managed production data with logical exports to an isolated analytics environment.
Use different models only when ownership remains clear. A hybrid estate becomes dangerous when teams assume someone else is backing up or monitoring a self-hosted database.
What we see in Raff deployment work
The recurring operational gap is rarely the initial database installation. It appears later in backup verification, disk growth, patch timing, connection saturation, alert routing, and restore ownership.
Small teams frequently underestimate the time between “the database is running” and “the database is production-ready.” The most valuable managed-service benefit is therefore not avoiding one installation command. It is assigning repetitive operational work to a platform designed to perform it consistently.
Self-hosting still makes sense when it solves a documented technical or control requirement. The stronger teams write that requirement down, define the operational owner, and test recovery before moving production data.
How this applies on Raff
Raff supports both operating models.
A self-hosted database can run on a Raff VM, where your team controls the operating system and database configuration. You are responsible for installation, patching, monitoring, backups, restore tests, storage growth, high availability, and incident response.
Raff Managed Databases shifts more of the database platform to Raff. The current product pages describe managed engine options, backups and recovery features, monitoring, private connectivity, and optional high-availability capabilities that vary by engine and plan. Some engines or features may be marked as rolling out, so verify current availability before designing the application around them.
A common managed architecture is:
Application ↓ private or restricted connection Raff Managed Database
A common self-hosted architecture is:
Application VM ↓ private network Database VM ↓ Customer-operated backups, monitoring, patching, and recovery
Use Private Cloud Networks where supported to keep application-to-database traffic off the public path. Use Object Storage as part of a self-hosted backup design when the database’s backup tooling supports it, and test restoration rather than assuming object presence equals recoverability.
Do not copy prices or feature limits from this guide. Confirm the current engine catalog, versions, plan capacity, backup retention, HA behavior, networking, and pricing on the live product pages.