ElectraDB
Guides

Backups and point-in-time restore

Every ElectraDB plan, including Dev, includes continuous encrypted backups and point-in-time restore for the last 7 days. You do not schedule or pay for backups separately.

1. How PostgreSQL backups work on ElectraDB

Each database has two kinds of backup:

  • A full backup every day. A complete copy of the database files.
  • Continuous archiving of every change. PostgreSQL writes every change to its write-ahead log (WAL), and each piece of WAL is copied to backup storage as it completes. On high-availability plans a piece is shipped at least every 5 minutes; on single-node and Dev plans at least every minute.

Together they let us rebuild your database as it was at any second covered by the backups.

Backups are encrypted on the server before upload, with a key that belongs to that one database, and each database's backups sit in their own storage area. They stay in the database's region (see Regions and data residency).

The database page shows when the last full backup ran and when changes were last archived. We check every database's backups every 5 minutes and run automated restore tests every week.

2. How to restore a PostgreSQL database to a point in time

  1. Open the database and go to Restore to a point in time.
  2. Pick a time between the earliest and latest points shown. The form uses your local time.
  3. Optionally give the copy a name, then choose Restore.

A restore always creates a new database, on the same plan and in the same region, with its own hostname, port and password. Your original database keeps running untouched. Once you have checked the copy, switch your application over to it and delete the old database if you no longer need it. The copy is billed as a separate database.

Duplicate now does the same from the latest moment that is surely in backup storage: useful for a staging copy or a test.

With the API, send POST /api/v1/databases/{id}/restore with an optional target_time (with a time zone, for example 2026-10-01T09:30:00Z) and display_name. Without target_time you get the latest restorable point.

3. How far back can you restore?

You can restore to any second of the last 7 days. For a new database the window starts one minute after its first backup, which is taken while the database is set up, before it goes live.

A restore outside the window is refused with the earliest and latest times you can pick.

4. Restore a deleted database

When you delete a database it goes offline at once and billing stops, but its backups are kept for 7 days. During that time you can restore it like any other: open the deleted database from your list and restore it. By default the copy contains everything up to just before the delete.

After 7 days the backups are deleted permanently and the database can no longer be restored.

To make an accidental delete less likely, turn on deletion protection on the database page or with PATCH /api/v1/databases/{id} ("deletion_protection": true). A database labelled production starts with it on.

5. Things to know

  • A restore copies the whole database. In the copy, every object belongs to the copy's own owner role, and the original database's password does not log in to it.
  • Backups protect against failures of our infrastructure and against mistakes inside the 7-day window. For anything you must keep longer, take your own exports with standard PostgreSQL tools such as pg_dump, as the Terms ask.
  • Dev and single-node databases change plan by restoring into a new database on the plan you want (see Plans, resizing and storage limits).

Backups and restore are included in the plan price on every plan: see pricing.