PostgreSQL hosting: managed service or a self-managed CPU VM?

PostgreSQL hosting gives your database the compute, storage, and network access it needs to serve an application. The first decision is who will operate it: a managed database provider, or your team on a virtual machine.

Choose managed PostgreSQL when the service meets your technical requirements and you want the provider to handle defined maintenance and recovery functions. Consider a self-managed CPU VM when you need control over the operating system, PostgreSQL configuration, or extensions, and someone can own updates, access, backups, and incidents. A lower VM rate does not settle that comparison.

This guide is a documentation-based decision aid, not a tested deployment or a provider ranking. The Hivenet example is limited to its documented development and testing use case. No PostgreSQL instance, cloud recovery procedure, or performance benchmark was run for this article.

Start with the database requirements

Write down what the database must support before comparing plans. A disposable development database, an internal reporting tool, and a customer-facing application have different consequences when a machine stops or data is lost.

• Data: current size, expected growth, sensitivity, retention, and required location.
• Workload: ordinary and peak connections, read/write mix, expensive queries, scheduled jobs, and acceptable response times.
• Compatibility: PostgreSQL major version, extensions, required privileges, and tools used for migration.
• Recovery: how much recent data you can lose and how long the application can remain unavailable.
• Ownership: who installs updates, investigates slow queries, responds to alerts, and restores data.

If nobody can take responsibility for recovery, start by evaluating a managed service with suitable restore features and support. You still need to test those features and understand their limits, but an unattended VM does not remove the work.

Managed PostgreSQL or a self-managed VM?

Managed hosting moves defined operations to the provider

A managed database service packages PostgreSQL with provider-operated features. The exact division of responsibility depends on the service, plan, and configuration. Read the backup, maintenance, availability, and access documentation together.

For example, Amazon RDS for PostgreSQL supports backups, point-in-time restores, Multi-AZ deployments, and read replicas. It does not provide SSH access to the database host and restricts some privileged operations. Those constraints matter if your application expects operating-system access or unrestricted administration.

DigitalOcean’s PostgreSQL documentation describes scheduled maintenance, daily backups with write-ahead logs for point-in-time recovery within the previous seven days, and automated failover for databases with a standby node. The standby requirement is important: do not read a general high-availability feature as a property of every configuration.

These are examples of what to verify, not a shortlist ranked by quality or price. Your team still owns application queries, schema changes, database permissions, credentials, connection behavior, and checks that restored data is usable.

A CPU VM gives you control and operating work

On a self-managed VM, you install PostgreSQL directly or run it in a container. You choose the supported database version and configuration, within the limits of the host and software. This can help with an unusual extension, an existing administration process, or a development environment that needs a close match to another system.

You also arrange operating-system and database updates, service supervision, secure access, disk capacity, backups, and recovery. A container makes packaging repeatable; it does not supply an availability design or turn a data volume into a backup.

For a small test project, that work can be deliberate learning. For an important application, it becomes an ongoing responsibility with an owner and a response plan. Count it when comparing the options.

A quick decision checklist

• Limited database operating capacity: favor a managed service whose maintenance, restore, and support terms meet your requirements.
• Need for host access or a specific extension: check the managed service’s supported features first; evaluate a VM if those limits block the workload.
• Disposable development data: a VM can be a useful test environment if you accept its lifecycle and can recreate the database.
• Strict recovery or availability requirements: compare verified configurations and procedures. Neither the word “managed” nor a running VM proves the requirement is met.
• Cost is the deciding factor: compare the complete setup and operating time at the same service requirements.

Check version and extension compatibility before migrating

Record the PostgreSQL major version and every required extension, including their versions. Check whether the destination permits installation and upgrades and whether your application needs privileges the service restricts. Do this before committing to a plan or copying data.

Use an isolated copy of representative data to test the application’s important queries and migration steps. Include extensions, roles, permissions, and scheduled work. A successful connection only proves that a client reached the server and authenticated; it does not establish compatibility or performance.

Also decide how you will leave the service. Identify the export or backup format, the target environment, and the restore procedure. A documented exit path is more useful than assuming every PostgreSQL-based service behaves identically.

Size PostgreSQL around queries, memory, and storage

CPU count is one input. Query execution, indexes, concurrent work, memory, disk latency, storage throughput, and network distance can all affect response time. Start with the workload you need to run rather than a universal “users per vCPU” rule.

Use our vCPU vs. physical core guide to understand CPU allocation and plan a repeatable capacity comparison. More vCPUs will not fix every slow query or storage bottleneck.

PostgreSQL’s resource configuration documentation explains why memory settings need care. In particular, work_mem is a limit for individual query operations such as sorts and hash tables, not a single budget for the whole server. Multiple operations and sessions can consume memory at once. Leave room for PostgreSQL’s other memory use and the operating system.

Estimate storage for more than the current table data. Allow for indexes, write-ahead logs, temporary files, maintenance, and growth. Ask how the selected storage behaves during a restart or host failure, what limits apply to disk performance, and what happens when the disk fills.

Test normal traffic, a peak period, and maintenance or reporting work that overlaps with requests. Record latency, errors, connections, CPU and memory use, and storage behavior. These are proposed acceptance checks; this guide does not provide benchmark results.

Before attributing a slow workload to VM size, find expensive PostgreSQL query patterns with pg_stat_statements. Compare call count, mean time, and cumulative execution time over a defined observation window. Statement totals alone do not identify a CPU bottleneck.

Budget connections across the application

Each application process may maintain its own connection pool. Increasing API instances or worker processes can therefore increase database connections even if each pool looks small. Account for background jobs, migrations, and administrative access as well as ordinary requests.

Set a connection budget before increasing application concurrency. If you evaluate a pooler, check how its pooling mode interacts with session state and the application’s driver. Pooling manages connections; it does not create more database CPU or storage capacity.

When you need to share database connections across application workers, use the PgBouncer pool-mode and compatibility guide. It explains how to budget connections across pooler instances and check session state and prepared queries before choosing transaction pooling.

Keep database access narrow

Decide which applications and administrators need access, from where, and through which network path. Keep the database off unrestricted public access. Use narrowly scoped network rules, appropriate database roles, protected credentials, and verified TLS where connections cross a network that requires it.

Place the application and database with latency and transfer costs in mind, but verify the available private-network arrangements. Do not assume that two services from the same provider can communicate privately by default.

Our API hosting guide covers the surrounding runtime decision. You can run the API on a VM and use a managed database, or operate both yourself. Choosing a VM for application code does not require keeping the database on that same machine.

Separate persistence, backups, and availability

Persistent storage keeps data across the lifecycle events it supports. Backups provide a recoverable copy. Replication and failover address other failure scenarios. Write down which capability you are buying or building; do not substitute one for another.

Define a recovery point objective, the acceptable amount of lost recent data, and a recovery time objective, the acceptable duration of recovery. Then check whether the selected backup retention, restore process, and availability configuration can meet them.

The PostgreSQL backup documentation distinguishes SQL dumps, file-system backups, and continuous archiving. Our PostgreSQL backup and restore guide explains a logical backup workflow and its limits. Its commands are documentation-based and were not executed against a PostgreSQL server for that guide.

For the environment you choose, restore into an isolated destination and check records, permissions, and application behavior. Keep recovery material outside the failure boundary of the original VM. Record the result and the time required; a scheduled backup job alone does not prove recoverability.

Compare the complete hosting cost

Include database compute, storage growth, backup retention, standby or replica capacity, data transfer, logs, support, and any pooler or proxy charges. For a VM, include the people and time needed to maintain it. For a managed service, include features that require a larger plan or additional nodes.

Use the same workload, region requirements, retention, and recovery expectations on both sides. A single development VM and a managed configuration with standby capacity solve different requirements, so their headline prices are not a fair comparison.

Our compute pricing guide provides a full-bill checklist. Confirm current prices and availability when evaluating the actual configuration. This article does not claim that either hosting model is always cheaper.

Where a Hivenet CPU VM fits

Hivenet’s vCPU documentation lists database hosting for development or testing among its CPU-only workloads. That makes a self-managed PostgreSQL test environment a reasonable use case to evaluate, with configuration, location, storage behavior, and connectivity confirmed first.

Check the lifecycle before storing anything you need to keep. Hivenet’s stop and terminate documentation says stopped instances expire after 10 days and their local data is deleted; termination deletes the instance and its local data. Keep a separate recovery copy and do not rely on a stopped instance as long-term storage.

This does not establish a managed PostgreSQL service, automatic database backups, failover, or production database suitability. Those requirements need separate evidence and an operating plan. For a development or testing evaluation, discuss the CPU workload with Hivenet. Bring the database size and growth, query and connection pattern, required location, storage needs, and recovery expectations.

For a self-managed development exercise, test PostgreSQL with Docker Compose on a CPU VM. The walkthrough separates private networking, application access, and persistence checks, and labels the container and cloud steps that remain untested.

Make the choice with a small acceptance test

Choose the hosting model that fits both the application and the team’s ability to operate it. Before moving important data, use an isolated dataset to check compatibility, authorized and rejected access, representative queries, restart behavior, and recovery.

Record what passed, what failed, and what remains untested. If a required feature or recovery result is missing, resolve it before treating the environment as ready. The next useful decision is a configuration and an owner for the database, backed by evidence from the workload itself.