Built to recover.
Continuous backups to two countries, restores proven on a schedule, and capacity kept free in every location to rebuild a failed host — with our commitments in writing.
Commitments, in writing.
Every figure here is part of our SLA or our published plans. The reliability figures are measured continuously, per service, and shown in your dashboard.
Backed by service credits — including when the outage is our provider's fault.
Monitored continuously and shown for every service.
Written independently to Germany and to France, so a problem in one country can't reach both.
One flat price. No compute units, no egress fees.
Architecture
How your service is built.
Each Balta service is a single PostgreSQL instance on dedicated hardware. If a host fails, your service is rebuilt from a verified backup onto capacity kept free in the same location — at the same connection address. Automatic failover with a standby is next on our roadmap.
- Backups
- Continuous, to two EU countries
- Restore tests
- Automatic, on a schedule
- Recovery point
- Five minutes or better
- Recovery capacity
- Kept free in every location
- Connection address
- Stays the same after a rebuild
What happens when something fails.
| What fails | What happens |
|---|---|
| PostgreSQL restarts, or the host reboots | Automatic restart and replay of recent changes. No data is lost. |
| A host is lost | Your service is rebuilt from a verified backup on another host in the same location, using capacity kept free for exactly this. |
| A whole location becomes unavailable | Your data is safe — a second backup repository is in another EU country. Your service is restored when the location recovers, or moved where that’s practical. |
Recovery point
A recovery point you can restore to.
Your recovery point is the latest moment we could actually restore you to. It needs a verified backup and an unbroken chain of changes after it — not just a recent upload. We check it continuously, separately for each repository, and show it for every service.
Under normal operation it stays at five minutes or better. If PostgreSQL restarts on a healthy host, your recovery point is zero: recent changes are still on local storage and are replayed.
Example view with sample data.
Verification
Backups we’ve actually restored.
On a schedule based on your database size, we restore one of your real backups into an isolated environment, replay every change, start PostgreSQL, check it and record how long it took. You see when your backup was last proven restorable — not just when it was taken.
| Database size | Full restore test |
|---|---|
| Up to 50 GiB | Every 7 days |
| 50 to 250 GiB | Every 14 days |
| 250 GiB to 1 TiB | Every 30 days |
| Over 1 TiB | Every 60 days, plus a monthly point-in-time test |
A test also runs within 48 hours of your first backup, and after every plan, storage or major version change.
Reserve capacity
Capacity kept free for recovery.
Every location keeps enough capacity free to rebuild a failed host’s services on the hosts that remain. It’s sized from the largest host in the location, so it grows as the location grows. When that reserve runs low, we add hardware and pause new services in that location — before the reserve is ever touched.
That reserve is part of what you pay for, and it’s never sold to anyone else.
Maintenance
Maintenance, announced.
Each service has a weekly maintenance window. Anything with expected impact is announced at least 72 hours ahead, and if work runs past the announced time, it counts against our uptime commitment. If an incident affects your service, you’ll hear from us by email.