Sign in
Managed Databases

Restore to a new database

Restore a database into a NEW instance. In-place restore is not supported — it would destroy the backup timeline it restores from — so clone_to_new must be true.

Choose the restore point with backup_id (a specific completed backup) or, for PostgreSQL, pitr_timestamp (any point in time covered by continuous WAL archiving). Omit both to restore the latest available state.

The clone inherits the source's plan, storage, VPC, and project, starts with no read replicas, and bills pay-as-you-go. High availability is an explicit choice via ha_enabled — never inherited. If new_name is taken, the platform auto-suffixes it (-2, -3, …).

The clone provisions asynchronously; poll GET /api/v1/databases/{new_database_id} like any create.

post/api/v1/databases/{database_id}/restore

Path parameters

database_idstring required

Database ID (UUID) or short id (the database_id field, e.g. a1b2c3d4)

Request body

clone_to_newboolean required

Must be true — restores always create a new database; in-place restore is not supported

backup_idstring uuid

Restore from this completed backup. Omit to use pitr_timestamp or the latest state.

pitr_timestampstring date-time

Point-in-time restore target (RFC 3339). PostgreSQL only — Valkey restores from snapshots via backup_id.

new_namestring

Name for the new database. Defaults to {source-name}-restored; auto-suffixed (-2, -3, …) if taken.

ha_enabledboolean

Enable high availability on the new database (+70% of the plan price). Never inherited from the source.

Response

Restore started

successboolean
new_database_idstring

Short ID of the new database being created

Changes