1. How high availability works
A high-availability database has two members:
- a primary, which takes reads and writes, and
- a standby in another site of the same region, which receives every change from the primary.
Your application connects to one hostname. Our servers route connections on your database's port to whichever member is currently the primary, so you never change connection strings.
If the primary's server fails, the standby is promoted automatically, around the clock, with no one to page and nothing to click. Connections that were open to the old primary are closed; your application reconnects to the same hostname and reaches the new primary. Use a driver or connection pool that reconnects on errors.
After a failover your database keeps running on one server. If the failed server does not come back, we rebuild a new standby on another server from backups. Your database page shows the redundancy state while that happens. The primary does not switch back afterwards: roles stay where the failover left them.
The standby is always in the same region, never on another continent (see Regions and data residency).
2. Replication modes: sync, write and async
You choose how each commit is copied to the standby. Change it on the database page under Replication, or with PATCH /api/v1/databases/{id} and "replication": "sync" | "write" | "async". The change applies within a minute, without a restart.
| Mode | A commit returns when | In a failover |
|---|---|---|
Synchronous (sync, default) | the standby has the change on disk | no committed data is lost |
Write-synchronous (write) | the standby has received the change, before it reaches its disk | data is lost only if both servers fail at the same moment |
Asynchronous (async) | the primary has it on its own disk; the standby is not waited for | the last commits can be lost |
What this means for your writes
Every synchronous commit waits for a round trip to the other site. That wait is added to each write transaction, not to reads. Write-synchronous waits a little less, because the standby does not have to write to disk before it answers. Asynchronous commits are as fast as on a single server.
Choose sync when losing an acknowledged write is not acceptable, such as for payments or orders. Choose write when you want faster commits and can accept a very small risk that requires both servers to fail together. Choose async for workloads where the last moments of data can be replayed or lost, such as caches, analytics or bulk imports. You can switch modes at any time, for example to async during a large import and back to sync afterwards.
If the standby is unavailable, a synchronous database does not block: the primary keeps accepting writes without waiting for a standby until one is back.
3. The read replica endpoint
Every high-availability database also has a read-only endpoint: the same hostname and credentials on a second port, shown on the database page. It reads from the standby when the standby is healthy and close to the primary, and falls back to the primary otherwise, so it never goes dark. Reads there can be slightly behind the primary, and writes are rejected. Extra replicas beyond the standby are not offered yet.
4. Single-node and Dev plans
Single-node plans have the same size, backups and 7-day restore as their high-availability counterparts, for 30% less, on one server. If that server fails, we restore the database from backup on another server automatically, with the same connection string. It is down while that happens and can lose up to about the last minute of writes. Dev is a single-node plan for development and testing.
Single-node and Dev databases have no read replica endpoint, no replication setting and no in-place plan changes.
5. Uptime commitment
Paid databases, high-availability and single-node, are covered by our Service Level Agreement: 99% monthly uptime, backed by service credits. Each database page shows the uptime measured this month, and the status page shows each region's health. Compare plans on the pricing page.
More guides
- Quickstart: create a managed PostgreSQL database and connectCreate a managed PostgreSQL database on ElectraDB and connect from psql, Python, Node.js, Go or Java with verified TLS.
- Backups and point-in-time restoreHow ElectraDB backs up PostgreSQL continuously, and how to restore a database to any second of the last 7 days, even after deleting it.
- Security: TLS, passwords, IP allowlist and encryptionHow ElectraDB secures managed PostgreSQL: verified TLS, one-time passwords, IP allowlists, encrypted backups, API keys and two-factor sign-in.
- Plans, resizing and storage limitsChoose an ElectraDB PostgreSQL plan, change plans without downtime, and learn what happens when a database reaches its storage limit.
- When your database is fullA database that reaches its plan's storage becomes read-only. How to free space and get writes working again.
- Regions and data residencyChoose where your ElectraDB PostgreSQL database lives: EU, US or Asia. Your database, its standby and its backups stay in that region.
- Frequently asked questionsAnswers about ElectraDB managed PostgreSQL: high availability, backups, point-in-time restore, regions, security, plans and billing.