Postgres hosting means the infrastructure and operating model used to run PostgreSQL for an application: compute, storage, connections, backups, monitoring, maintenance, scaling, and recovery.
For a SaaS team, the practical choice is usually between managed PostgreSQL hosting and self-hosted PostgreSQL. Managed PostgreSQL reduces platform operations; self-hosting gives deeper host and database control but makes your team responsible for patching, backups, monitoring, failover, storage growth, upgrades, and recovery.
Raff Technologies supports both paths. If standard PostgreSQL versions and extensions fit your workload, Raff Managed PostgreSQL is the lower-operations path. If you need root access, unsupported packages, custom topology, or direct host control, PostgreSQL can also run on a Raff VM.
For most small SaaS teams, the decision should start with operational ownership and recovery requirements, not with the cheapest server size. Choose the operating model first, then size CPU, memory, storage, connections, backups, and availability from workload evidence.
Postgres hosting: managed vs self-hosted at a glance
| Responsibility | Managed PostgreSQL | Self-hosted PostgreSQL |
|---|
| Database provisioning | Provider | Your team |
| Operating-system maintenance | Provider | Your team |
| Database service maintenance | Provider within service policy | Your team |
| Backup platform | Provider-operated within plan scope | Your team designs and operates it |
| Point-in-time recovery | Service capability when included | Your team configures and validates it |
| Monitoring platform | Usually included to a defined scope | Your team selects and operates it |
| Connection pooling | May be included | Your team deploys and maintains it |
| High availability | Service option | Your team designs, tests, and maintains it |
| Root and filesystem access | Restricted | Full control |
| Schema, indexes, and queries | Your team | Your team |
| Migration safety | Your team | Your team |
| Application reconnect behavior | Your team | Your team |
Choose managed PostgreSQL when the supported service fits and your team wants to reduce repetitive platform work.
Choose self-hosted PostgreSQL when a documented requirement needs operating-system access, unsupported extensions or packages, exact patch control, direct filesystem access, or a custom replication topology.
The key word is documented. “We want more control” is not enough unless someone also owns backup verification, patching, monitoring, recovery, and incidents.
What managed PostgreSQL hosting actually changes
A managed PostgreSQL service does not remove database responsibility. It changes the boundary of responsibility.
The provider typically operates more of the platform layer, such as:
- database provisioning;
- service and operating-system maintenance;
- backup infrastructure;
- point-in-time recovery tooling;
- monitoring and service health;
- storage expansion workflows;
- connection-pooling options;
- supported high-availability and failover controls;
- networking and access controls;
- version and maintenance workflows.
Your application team still owns:
- schema design;
- indexes;
- query performance;
- migrations;
- application credentials and roles;
- connection behavior;
- capacity decisions;
- data-retention policy;
- recovery-point selection;
- validating that the application works after recovery.
This is why managed PostgreSQL is most useful when database operations are necessary but are not your product.
Self-hosted PostgreSQL gives control by transferring work to your team
Self-hosting PostgreSQL on a VM can be the correct architecture when the application needs capabilities outside a managed-service boundary.
Typical reasons include:
- root or operating-system access;
- a PostgreSQL version not supported by the target managed service;
- an extension or package outside the approved catalog;
- custom authentication modules;
- direct database-file or filesystem access;
- exact patch timing;
- a custom replication or clustering topology;
- local processes that must run beside PostgreSQL;
- infrastructure requirements defined by an internal platform or contract.
The trade-off is complete lifecycle ownership:
VM provisioning
+ OS hardening
+ PostgreSQL installation
+ configuration
+ patching
+ TLS
+ firewall rules
+ monitoring
+ alerts
+ backups
+ restore tests
+ storage growth
+ replication
+ failover
+ major-version upgrades
+ incident response
Installing PostgreSQL is easy. Operating it safely through failures, growth, and upgrades is the real self-hosting cost.
For the VM path, see VPS for Databases and the PostgreSQL on Ubuntu 24.04 tutorial.
PostgreSQL hosting decisions should follow workload evidence
There is no reliable mapping from “number of users” to a fixed PostgreSQL server size. Two SaaS products with the same user count can have very different query complexity, connection patterns, write rates, working sets, and recovery requirements.
Collect these inputs before choosing a production plan:
- peak active transactions;
- number of application instances and workers;
- pool size per application process;
- p50, p95, and p99 query latency;
- database and index size;
- storage growth over time;
- read-to-write ratio;
- temporary-file activity;
- WAL generation rate;
- storage latency during normal and peak periods;
- backup size and measured restore time;
- expected growth over the next planning cycles.
CPU pressure can come from legitimate query work, but it can also come from missing indexes, repeated queries, large sorts, or retry storms. Increase compute after checking whether the work itself is necessary.
Memory supports PostgreSQL buffers, operating-system cache, connections, sorts, hashes, maintenance work, and extensions. Watch swapping, out-of-memory events, large temporary files, and latency that appears only under concurrency.
Storage should include capacity and operational headroom:
production data + indexes
+ WAL and temporary work
+ expected growth
+ migration and maintenance headroom
+ safety margin
A database can serve traffic normally and still have a restore time that exceeds the business RTO. Restore duration is therefore a production sizing input, not just a backup detail.
Connection budgets can fail before CPU does
PostgreSQL capacity planning should include connections, not only CPU and RAM.
Estimate planned demand as:
maximum app instances
x pool size per instance
+ background workers
+ scheduled jobs
+ migration connections
+ monitoring
+ administrative reserve
= planned database connection demand
For example, six application instances with pools of 10 connections can consume 60 potential server connections before workers, migrations, monitoring, or administration are counted.
More connections do not automatically create more throughput. Excessive concurrency can increase memory pressure, lock contention, context switching, and queueing.
A pooler such as PgBouncer can separate application concurrency from PostgreSQL server concurrency. Applications that depend on session-level state should still be checked for pooling compatibility.
Monitor active and idle connections, pool wait time, long and idle transactions, rejected connections, connection churn during deployments, and retry behavior.
A database with spare CPU can still become unavailable when every connection slot is occupied.
Backups, PITR, replication, and high availability protect different failures
Production PostgreSQL hosting should separate availability from historical recovery.
| Control | Primary purpose | Main limitation |
|---|
| Logical backup | Portable or selective recovery | Can be slow for large full restores |
| Base backup + WAL archive | Full recovery and point-in-time recovery | Requires complete retention and restore testing |
| Standby replication | Availability and eligible read scaling | Usually reproduces accidental changes |
| High availability | Faster recovery from selected node failures | Does not replace historical recovery |
| Infrastructure snapshot | Infrastructure rollback aid | Not a complete PostgreSQL recovery strategy |
| Restore test | Proves procedure and timing | Does not prevent the original incident |
Replication is not a backup. A replica can receive accidental deletes, destructive updates, and bad migrations along with valid writes.
Define two business targets before choosing protection layers:
- RPO: how much recent data the business can afford to lose.
- RTO: how long the database and application can remain unavailable.
A daily dump cannot satisfy a 15-minute RPO. A standby may shorten recovery from node failure but does not provide a clean historical point before a destructive write. PITR provides historical recovery, but the team still needs to validate the restored data and reconnect the application safely.
Use PostgreSQL Replication vs Backups vs Snapshots for the detailed failure-mode comparison and Database Backup Strategy for SaaS Apps for retention and restore planning.
When managed PostgreSQL is usually the better SaaS fit
Managed PostgreSQL is usually the simpler starting point when:
- the application uses supported PostgreSQL versions and extensions;
- the team has no dedicated database operator;
- backup and recovery ownership should be clearer;
- connection pooling is useful;
- private or restricted connectivity fits the architecture;
- the workload needs a straightforward scaling path;
- optional high availability is valuable;
- engineering time is better spent on schema, queries, and product behavior.
This is a commercial decision as much as a technical one. The managed service may cost more than one raw VM, but the comparison should include engineering time, on-call ownership, backup infrastructure, monitoring, standby capacity, restore testing, and incident recovery.
If this model fits, evaluate Raff Managed PostgreSQL rather than comparing only VM prices.
When self-hosted PostgreSQL is justified
Self-hosting becomes stronger when at least one hard requirement falls outside the managed service:
- required extension or package is unavailable;
- root access is mandatory;
- filesystem access is part of the application architecture;
- exact version or patch control is required;
- custom replication or failover topology is necessary;
- database operations are already a mature internal capability;
- compliance or platform policy requires deeper infrastructure ownership.
If none of these apply, self-hosting can create an internal database platform that a small product team must maintain without gaining meaningful product value.
For the broader decision framework, see Managed vs Self-Hosted Databases.
What Raff Managed PostgreSQL currently provides
Raff's live PostgreSQL product page currently lists PostgreSQL 14 through 16, built-in connection pooling, backups with point-in-time recovery, monitoring, TLS and IP allowlists, private networking, storage expansion, optional high availability, and extensions including pgvector and PostGIS. Current capabilities and limits should always be checked on the live Managed PostgreSQL page before production design.
Raff also provides a free managed-database entry point. The live PostgreSQL page currently shows 1 GB memory, 2 GB storage, and daily backups for the free starting tier. Raff's release notes state that the free database plan is limited to one free database per account and may pause after seven days without a connection. Treat the free tier as an evaluation, development, prototype, or light-workload starting point—not as a universal production sizing recommendation.
A managed architecture can remain compact:
Application
-> private or restricted connection
Raff Managed PostgreSQL
-> managed platform operations
-> customer-owned schema, queries, and application behavior
A self-hosted architecture on Raff VMs shifts more work back to the customer:
Application VM
-> private network
PostgreSQL VM
-> customer-operated patching, backups, monitoring, pooling, HA, and recovery
The correct model is the one your team can operate and recover reliably at the required service level.
PostgreSQL hosting buying checklist
Before choosing a provider or plan, write down:
- Required PostgreSQL major version.
- Required extensions.
- Current database and index size.
- Expected monthly storage growth.
- Peak application and worker connections.
- Required RPO and RTO.
- Whether high availability is required.
- Backup retention requirement.
- Private-network or public-access requirements.
- Who owns restores and production incidents.
- Expected migration or exit path.
- Total operating cost, including engineering time.
If these are unknown, comparing monthly plan prices is premature.
Conclusion
Postgres hosting is not only a server-size decision. Start with the responsibility boundary, then validate connections, query behavior, memory, storage growth, RPO, RTO, and restore time before choosing the production shape.
Managed PostgreSQL is usually the practical choice when the supported service fits and the team wants a smaller operational surface. Self-hosting is justified when a specific technical or control requirement outweighs the additional maintenance and recovery work.
For SaaS teams evaluating Raff, the next step is straightforward: compare the live Managed PostgreSQL service against the requirements above. If a hard requirement falls outside the managed boundary, evaluate PostgreSQL on a Raff VM instead.
