Reliability
A backup you have not restored is not a backup
Durability claims are easy to make and hard to keep. Here is exactly what WebyneDB does to protect your data today, and what is still being built.
Backup and recovery
Daily backups by default, with configurable retention per database.
Daily backups by default
AvailableConfigurable retention per database.
On-demand backups
AvailableTake one before a risky migration, from the dashboard or API.
Verified restores
AvailableEach backup is restored into a scratch instance and its objects counted before it is trusted.
Safety copy before restore
AvailableRestoring over a live database takes a backup first, so a wrong choice is recoverable.
Higher-frequency policies
On the roadmapMore frequent backup schedules for enterprise plans.
Continuous WAL archiving
On the roadmapTransaction-log archiving for point-in-time recovery.
Off-host and cross-DC copies
On the roadmapBackups stored away from primary compute, with a second data centre option.
Enterprise DR replica
On the roadmapAsynchronous replica in a second Webyne data centre with documented RPO and RTO.
How a backup becomes trustworthy
- 1
Dump
The engine streams a dump straight through compression to disk. Nothing is buffered in memory, so database size does not limit the backup.
- 2
Checksum
A SHA-256 checksum is computed in the same pass, so silent corruption on disk is detectable later.
- 3
Restore test
The backup is restored into a throwaway instance of the same engine and version — never your live database.
- 4
Verify
The recovered objects are counted and the scratch instance destroyed. Only now is the backup marked verified.
Restoring over a live database takes a safety copy first
A restore is destructive by definition. Before one runs, WebyneDB takes a fresh backup of the current state, so restoring the wrong snapshot is recoverable rather than final.
High availability
The target design for mission-critical PostgreSQL, and where it stands today.
| Component | Role | Status |
|---|---|---|
| HAProxy / PgBouncer | Routes customer traffic to the current primary and pools connections. | On the roadmap |
| Patroni | Manages leader election and failover. | On the roadmap |
| etcd | Distributed consensus for the cluster. | On the roadmap |
| Streaming replication | Keeps one or more replicas current with the primary. | Available |
| pgBackRest | Backup and WAL archiving for point-in-time recovery. | On the roadmap |
| Prometheus exporters | Database and host telemetry. | On the roadmap |
What you can run today
PostgreSQL streaming replicas, seeded from a base backup of the primary and kept current over a replication stream. Replicas are read-only, their lag is reported live, and they can be promoted to primary when you decide to.
Why failover is still manual
Automatic failover needs a consensus layer to agree on which node is the leader. Promoting a replica on a heuristic — without that agreement — is how a cluster ends up with two primaries and diverging data. Until the consensus layer is in place, promotion stays an operator decision.
Recommended HA topology
One primary and two replicas, placed across separate failure domains where the infrastructure allows. The control plane tracks cluster health continuously, but failover is designed to stay safe even if the customer portal is temporarily unavailable — your database does not depend on our dashboard being up.
Have an RPO and RTO you need to meet?
Tell us the targets and we will tell you plainly whether we can meet them today.