Managed vs Self-Hosted Databases: What You Take On

Decide whose time pays for database operations

The money goes into running the database and keeping recovery available when something fails. With self-hosting, the infrastructure bill can look modest while the hours appear later, during maintenance or an unexpected outage. We recommend managed Postgres when nobody has protected time to own those jobs.

Self-hosting is a sensible choice when you understand the failure you are accepting. Our baseline here is PostgreSQL on a single VPS running Ubuntu 24.04 LTS, potentially alongside your application. That keeps the system understandable, but losing that machine stops everything on it until you recover.

Compare complete operating arrangements rather than a database service against an empty server. Your self-hosted arrangement needs independent backup storage and someone who responds to alerts. A managed arrangement needs a suitable service configuration and someone who understands its recovery controls. The broader VPS versus cloud decision helps separate infrastructure spending from work you are buying.

We would self-host a small application whose users can tolerate a recovery window, provided the recovery procedure is already usable. We would choose managed service when an unavailable operator could turn a routine failure into a business emergency. Familiarity with installing Postgres is useful, but it does not answer that staffing question.

Separate managed infrastructure from your remaining duties

An unmanaged database usually means you install and operate the database yourself on rented infrastructure. A managed database moves a defined set of operational duties to the provider. Read that definition before buying, because a managed label does not establish which failures receive automatic recovery.

A useful example is the DigitalOcean shared responsibility model, which leaves user permissions and query optimization with the customer. Its service supplies recovery facilities, but you still decide how the application uses them. Treat this as an example of where to look, rather than a promise that every provider divides work identically.

Before selecting a service, confirm support coverage and the maintenance controls available to you. Check whether your required extensions are supported and whether administrative restrictions affect your tooling. Our DigitalOcean review is a useful companion when considering the hosting arrangement, while the database service documentation should govern your database decision.

Choose acceptable recovery before choosing a host

Write down how much recent data the business can lose and how long it can operate without the database. These are separate limits. A recent backup can protect most of your data while still leaving you with a lengthy restore, especially if replacement infrastructure or credentials are difficult to obtain.

For a quiet application, scheduled logical backups may fit those limits. If losing changes since the latest dump would be unacceptable, investigate continuous archiving with point-in-time recovery. PostgreSQL documents how a base backup and the required write-ahead log archive support recovery to a chosen point; a logical dump alone cannot provide that replay capability. Use the PostgreSQL recovery documentation to understand the requirements.

Store recovery material outside the database machine, with access that survives losing that machine. Keep the decryption material available through a separate recovery path. A backup file sitting beside the live database is convenient for a local mistake, but cannot be your answer to losing the VPS.

For managed service, establish the retained recovery window and whether restoration creates a new endpoint. Ask what happens if your account becomes inaccessible or the service is accidentally deleted. For self-hosting, follow the Postgres backup and restore drill procedure before accepting production writes.

Accept a single server's downtime or fund another design

A single VPS is a reasonable production design when you explicitly accept its outage behavior. It gives you a clear place to inspect logs and a small amount of infrastructure to maintain. It also leaves the application unavailable during a host failure, even if every backup is healthy.

Separating Postgres onto another VPS can isolate it from application resource pressure and deployment mistakes. It does not, by itself, give you database failover. You have added a network dependency and another machine to maintain, so make that move to solve a specific isolation problem.

Replication changes the recovery options, but it adds operational decisions. PostgreSQL streaming replication is asynchronous by default, so committed changes can be missing from a standby when the primary fails. Replication slots also require attention because retained write-ahead logs can exhaust storage. The PostgreSQL standby documentation explains those trade-offs.

We would buy an appropriate managed availability configuration before asking a lightly staffed team to operate automatic failover. Verify what the chosen configuration actually includes, then exercise application reconnection against it. A replica also follows valid destructive writes, so it cannot replace recovery history when an application deletes the wrong data.

Budget for the work after installation

Installing Postgres is the easy part of self-hosting. The recurring work includes reviewing storage growth and preparing upgrades before they become urgent. Someone must also distinguish ordinary background activity from a problem that will interrupt writes.

• Track free storage and growth trends, including temporary files and retained database logs.
• Watch connection pressure and blocked transactions so an application fault does not look like a dead server.
• Alert on backup freshness and failures, with notifications delivered outside the affected VPS.
• Schedule database and operating system maintenance, with a recovery plan appropriate to the change.
• Rehearse restoration after meaningful changes to backup tooling or database configuration.

When the database shares a VPS with the application, account for build jobs and other competing work. Avoid treating every slowdown as evidence that Postgres needs larger memory settings. Inspect the workload first, and leave capacity for the operating system as well as transient application demand.

An HTTP health check can pass while a queue of blocked transactions is growing. Combine an external application check with database signals that can reveal approaching failure. The minimum monitoring setup for a small fleet gives you a practical starting point for alerts that reach an operator.

Give Claude Code bounded database work

Claude Code can reduce the effort of investigating a slow query or preparing a maintenance procedure. We recommend starting with narrowly scoped, read-only access and sanitized diagnostic material. You still need an operator who can judge the proposed change and recognize when the evidence is incomplete.

Keep the application's database role separate from migration privileges and routine diagnostic access. For local application connections, a Unix socket or loopback listener avoids needing a public database endpoint. For remote connections, restrict permitted clients and verify encrypted transport with server identity checks.

Read-only access is not harmless access: a query can consume substantial resources, and query results can expose private data. Use appropriate timeouts and avoid handing the agent production records when schema information will answer the question. Require explicit approval for production writes or changes that can interrupt service.

Ask the agent to present the intended effect and the evidence you will inspect afterward. For a risky migration, have it prepare a rehearsal against an isolated restored database before proposing production execution. The production agent guardrails help keep those permissions enforceable rather than dependent on a prompt.

Check migration friction before committing

Postgres compatibility makes moving data possible, but does not make every environment interchangeable. Check extension requirements and the privileges your maintenance tools need. Identify dependencies on provider-specific authentication or backup controls before they become embedded in your operating procedure.

For a modest database with an acceptable maintenance window, a dump and restore may be the clearest migration approach. Rehearse it against the destination and validate the application there. Include database roles and required extensions in the plan, rather than assuming that moving tables completes the move.

Keep the destination isolated from production side effects during rehearsal. A restored application can still send real notifications or consume live jobs if you reuse its production configuration. Verify the application against the recovered data without letting it act on external systems.

At cutover, stop writers to the old database before moving the authoritative copy and changing application connections. Once the destination accepts new writes, sending traffic back to the old database requires a data reconciliation plan. Choose the migration method around your downtime allowance, and use specialist help if continuous replication makes the procedure harder than your team can safely operate.

Run a recovery rehearsal before accepting production

Create a short operating document for the database you intend to use. Name the responsible operator and record the accepted recovery limits. Then perform the following rehearsal in an isolated environment, without changing the production connection.

1. Obtain a representative backup through the intended production backup mechanism. Record where recovery credentials and decryption material can be retrieved independently.
2. Restore into an isolated database and configure a disposable application instance to use it, with external side effects disabled.
3. Verify representative records and complete an application write followed by a read. Record elapsed recovery time and compare recovered data freshness with your accepted loss window.
4. Trigger a safe monitoring condition in the isolated environment and confirm that the responsible operator receives the notification.
5. Write the connection cutover procedure and identify who can authorize it during an incident.

If you cannot complete this rehearsal for a self-hosted database, choose managed Postgres and rehearse its recovery workflow instead. If both approaches meet your limits, choose the one whose recurring duties have a dependable owner. Put the next recovery rehearsal on that owner's calendar before directing production traffic to the database.