PostgreSQL replication, backups, point-in-time recovery, and infrastructure snapshots protect different failure modes. Replication improves availability. Backups preserve recoverable history. Point-in-time recovery restores the database to a chosen moment. Snapshots create fast infrastructure rollback points. None replaces the others.
For small teams, the common failure is treating a standby as a backup or treating a VM snapshot as complete database recovery. A replica can reproduce an accidental DELETE. A snapshot may capture a crash-consistent server state but not give you the exact recovery point the business needs.
Raff Technologies supports more than 3,000 customers and 15,000 VMs, and teams can now choose between self-hosted PostgreSQL on Raff VMs and live Raff Managed PostgreSQL. That changes who operates backup infrastructure, monitoring, pooling, and optional availability controls, but it does not change the underlying recovery principle: availability and historical recovery are separate responsibilities.
PostgreSQL protection layers solve different problems
| Protection layer | Primary purpose | Best protection against | Main limitation |
|---|---|---|---|
| Physical replication | Availability and eligible read scaling | Primary-server failure | Usually reproduces unwanted changes |
| Logical backup | Portable or selective restore | Object-level recovery and migration | Full restore time can grow significantly |
| Base backup + WAL archive | Full recovery and PITR | Accidental writes, corruption, chosen recovery point | Requires complete retention and restore testing |
| High availability | Faster service recovery after selected node failures | Node or service failure | Does not preserve historical versions |
| VM or volume snapshot | Fast infrastructure rollback | Failed upgrades and server-level changes | Not a complete PostgreSQL recovery method |
The correct design starts with the incident you need to survive, not with whichever tool is easiest to enable.
Replication protects availability, not historical recovery
PostgreSQL streaming replication keeps a standby close to the primary by replaying write-ahead log records. A standby can be promoted when the primary fails, and a hot standby can serve read-only traffic.
That makes replication useful for:
- reducing downtime after primary failure;
- planned maintenance;
- selected read-scaling patterns;
- custom failover architectures;
- disaster-recovery designs that span failure domains.
Replication does not create an independent historical copy. A healthy standby can contain the same damaged state as the primary after:
- an accidental deletion;
- an incorrect migration;
- application-written corruption;
- compromised credentials modifying data;
- an operator mistake applied successfully to the primary.
Streaming replication is asynchronous by default. That means a standby can lag and recently committed transactions may be missing after sudden failover. Synchronous replication can reduce that window but introduces a latency and availability trade-off because commits wait for standby confirmation.
Failover restores service continuity. It does not necessarily restore correct data.
PostgreSQL backups preserve an independent recovery path
Database backups protect the ability to return to a safe state after the current database state is no longer trustworthy.
Logical backups support portability and selective restore
Tools such as pg_dump are useful for:
- selective object or database restore;
- migration between compatible PostgreSQL environments;
- additional portable exports;
- recovery workflows that do not require the complete cluster.
Logical backups are valuable, but they are not automatically the fastest full-database recovery method. Restore time depends on database size, indexes, constraints, extensions, parallelism, and available compute.
Physical backups and WAL enable point-in-time recovery
A physical base backup combined with a complete WAL archive can recover PostgreSQL toward a chosen time or recovery target.
That answers different questions from replication:
- Can we recover to the moment before an accidental deletion?
- Can we rebuild after both primary and standby become unusable?
- Can we return to a state before a destructive migration?
- Can we meet the business recovery point objective?
The base backup and WAL archive form one recovery chain. Missing WAL files, broken retention, inaccessible credentials, or an untested restore process can invalidate the chain even when backup jobs appear successful.
For self-hosted PostgreSQL, your team owns that chain. For Raff Managed PostgreSQL, backup and PITR infrastructure are part of the managed service boundary while your application team still owns recovery-point selection, validation, migration safety, and application reconnect behavior.
Snapshots are fast rollback points, not database history
A VM or block-volume snapshot captures infrastructure state at a point in time. It is particularly useful before:
- operating-system upgrades;
- PostgreSQL package or version changes;
- storage reconfiguration;
- major configuration edits;
- extension installation;
- controlled maintenance with a defined rollback window.
Snapshots can shorten rollback after a recent server-level change because restoring infrastructure may be faster than rebuilding from a complete database backup chain.
The limitation is that infrastructure snapshots do not inherently understand PostgreSQL transactions, WAL boundaries, replica state, or application write activity. Depending on the capture method, the result may be crash-consistent rather than application-consistent.
PostgreSQL can normally recover from crash-consistent disk state using WAL, but that should be tested rather than assumed for a production recovery plan.
A snapshot should therefore support the database recovery strategy, not replace it.
The failure-mode matrix shows which control should lead
| Incident | Replication | Backup + PITR | Snapshot | Primary recovery control |
|---|---|---|---|---|
| Primary server fails | Strong | Useful but slower | Useful if recent | Replication or managed HA |
| Standby is behind | Limited by lag | Strong if WAL is complete | Limited | RPO-driven replication + PITR |
| Accidental row deletion | Usually weak | Strong | Coarse rollback | PITR or selective restore |
| Bad schema migration | Usually reproduces it | Strong | Useful before change | Backup/PITR + pre-change snapshot |
| Application corrupts data | Usually reproduces it | Strong | Depends on detection time | PITR to validated target |
| PostgreSQL or OS upgrade fails | Medium | Strong safety layer | Strong short-term rollback | Snapshot + verified backup |
| Account compromise | May copy damage | Strong only if access is isolated | Weak if same control plane is compromised | Protected retained backups |
| Broad infrastructure failure | Depends on replica placement | Strong if copies cross boundaries | Depends on snapshot location | Cross-domain recovery design |
No single mechanism wins this comparison. Each layer needs a defined job.
RPO and RTO determine the protection stack
Two business targets should drive the design:
- Recovery Point Objective (RPO): how much recent data the business can lose.
- Recovery Time Objective (RTO): how long the database and application may remain unavailable.
Replication can shorten RTO after primary failure. Continuous WAL archiving can improve the recoverable RPO after accidental writes. Snapshots can shorten rollback around controlled infrastructure changes.
Before selecting a design, answer:
- How much committed data can be lost after failover?
- How far back might the team need to recover after a logical mistake?
- How quickly must the database return to service?
- Which failures can affect the primary and standby together?
- Where are backups retained and who can delete them?
- When was the last complete restore test?
A backup job is not recovery evidence until the restore process has been exercised.
Managed PostgreSQL changes who operates the recovery platform
Raff Managed PostgreSQL currently supports PostgreSQL 14–16 with built-in connection pooling, backups with point-in-time recovery, monitoring, TLS, IP allowlists, private connectivity, storage expansion, and optional high availability.
The current Raff database console also includes a free PostgreSQL entry point with 1 vCPU, 1 GB RAM, 2 GB SSD, 60 direct plus 200 pooled connections, and one free database per account. That tier is useful for evaluation and development; production recovery and availability decisions should still follow measured workload requirements rather than the free-tier limits.
A managed PostgreSQL architecture can look like:
Application ↓ private or restricted connection Raff Managed PostgreSQL ↓ Managed backup/PITR + monitoring + optional HA
The managed service operates more of the database platform, but your team still owns:
- schemas and indexes;
- query design;
- credentials and application access;
- migration safety;
- capacity decisions;
- recovery-point selection;
- validation of restored data;
- application behavior after failover or restore.
Managed PostgreSQL reduces operational surface; it does not outsource responsibility for application correctness.
Self-hosted PostgreSQL needs a deliberately layered design
Self-hosted PostgreSQL on a Raff VM gives your team direct control over database version, extensions, storage, replication topology, WAL policy, maintenance timing, and recovery tooling.
That control means the team also owns:
- standby design and failover testing;
- base backups and WAL archiving;
- logical exports where needed;
- backup retention;
- restore testing;
- monitoring for replication lag and archive failures;
- disk-growth planning;
- database and operating-system patching;
- after-hours incident response.
Use Raff VPC for private connectivity between application and database systems. Use Data Protection for VM-level backup and snapshot controls, while keeping PostgreSQL-native backup and PITR as separate database recovery responsibilities.
A defensible self-hosted protection stack often includes:
- replication when rapid failover matters;
- physical backups plus WAL when PITR matters;
- logical exports for selective portability;
- snapshots before risky infrastructure changes;
- retained copies across appropriate failure and access boundaries;
- separate failover and restore tests;
- monitoring for replication lag, WAL archive health, backup age, storage growth, and restore readiness.
The decision framework separates availability from recovery
Choose replication first when the primary requirement is rapid continuity after server failure.
Choose backup plus WAL/PITR first when the primary requirement is recovery from accidental changes, corruption, compromise, or incidents discovered after replication copied the damage.
Use snapshots as a supporting control when fast rollback around a defined server or storage change matters.
Choose Raff Managed PostgreSQL when PostgreSQL 14–16 and the managed feature set fit the workload and the team wants backup/PITR infrastructure, monitoring, pooling, and optional HA without operating the complete PostgreSQL platform.
Choose self-hosted PostgreSQL when a documented requirement needs root access, exact package control, unsupported extensions, custom replication topology, or direct filesystem access.