Database snapshots

#What a database snapshot is

A snapshot is a copy of a database's data disk at one instant. You take it with one API call, while the database is running or stopped, and it is kept, and billed, until you delete it.

Three things to know before you rely on one:

• It is crash-consistent. The engine keeps running while the copy is taken, so the snapshot holds what the disk held at that instant, as if the power had been cut. PostgreSQL, MySQL and MariaDB all recover from that on start, but a transaction that had not committed is not in it. For a quiesced copy, stop the database first, snapshot it, then start it.
• Restoring from a snapshot is not available yet. There is no endpoint to create a database, or a volume, from a database snapshot today. Take snapshots now and you will be able to restore them when it arrives, but until then a snapshot is not a backup you can use on your own.
• It is not a logical backup. For a copy you can restore today, anywhere, into any version, take a dump with pg_dump, mysqldump or mariadb-dump. Use snapshots alongside dumps, not instead of them.

A snapshot outlives its database: deleting the database does not delete its snapshots, and they stay billed until you delete them yourself.

#Take a snapshot

In the console, press Take snapshot in the database's Snapshots card and name it. The database keeps running. The card lists the database's snapshots.

With the API:

$ curl https://api.pantechdynamics.com/public/v1/databases/db_…/snapshots \    -H "Authorization: Bearer $PANTECH_API_KEY" \    -H "Idempotency-Key: $(uuidgen)" \    -H "Content-Type: application/json" \    -d '{"name": "before-migration-42"}'

{
  "operation_id": "op_…",
  "resource_id": "snap_…",
  "status": "submitting"
}

• name is 1 to 255 characters, and must be unique among that database's snapshots (409 DATABASE_SNAPSHOT_NAME_TAKEN otherwise). Name it after why you took it: before-migration-42, pre-upgrade, 2026-10-05-nightly.
• The database must be running or stopped. While it is being created, changing power state or being deleted, the request is 409 DATABASE_SNAPSHOT_NOT_READY; wait for it to settle.
• resource_id is the new snapshot's id, snap_…. Follow the operation until it is succeeded (its resource_id is the snapshot's id too); the snapshot's observed_state is then active and completed_at is set.

The database keeps serving connections while the snapshot is taken.

#List and read snapshots

A database's own snapshots, oldest first:

$ curl https://api.pantechdynamics.com/public/v1/databases/db_…/snapshots \    -H "Authorization: Bearer $PANTECH_API_KEY"

{
  "data": [
    {
      "id": "snap_…",
      "name": "before-migration-42",
      "database_id": "db_…",
      "instance_id": null,
      "volume_id": null,
      "trigger": "manual",
      "size_bytes": 1879048192,
      "desired_state": "present",
      "observed_state": "active",
      "completed_at": "2026-10-05T09:14:02Z",
      "created_at": "2026-10-05T09:13:40Z",
      "updated_at": "2026-10-05T09:14:02Z"
    }
  ],
  "next_cursor": null
}

One snapshot is GET /databases/{database_id}/snapshots/{snapshot_id}. A snapshot id that is not one of this database's snapshots, such as a volume's snapshot, is 404 DATABASE_SNAPSHOT_NOT_FOUND.

Database snapshots also appear in your organization's snapshot list, with database_id set and instance_id and volume_id null. That is how you find the snapshots of a database you have already deleted.

size_bytes is the storage the snapshot uses, which is what it is billed on. It is 0 until the snapshot is complete.

#Delete a snapshot

$ curl -X DELETE https://api.pantechdynamics.com/public/v1/databases/db_…/snapshots/snap_… \    -H "Authorization: Bearer $PANTECH_API_KEY" \    -H "Idempotency-Key: $(uuidgen)"

The snapshot is billed until the deletion completes. After the database itself has been deleted, delete its snapshots with DELETE /snapshots/{snapshot_id}.

#Pricing

A database snapshot is billed like every other snapshot: the storage rate per GB of the space it uses, rounded up to whole GB, for every hour it exists. Nothing is billed while it is still being taken.

#With the CLI

$ pantech db snapshots create orders-db --name before-migration-42$ pantech db snapshots list orders-db$ pantech db snapshots get orders-db snap_…$ pantech db snapshots delete orders-db snap_…

create and delete wait for the operation to finish; pass --no-wait to return its id at once. delete asks first unless you pass --yes.

#With Terraform

In the provider's next release:

resource "pantechdynamics_database_snapshot" "before_migration" {
  database_id = pantechdynamics_database.orders.id
  name        = "before-migration-42"
}

Changing either argument replaces the snapshot: a new one is taken and the old one deleted. terraform destroy deletes it. Because a snapshot outlives its database, a snapshot resource left in your configuration keeps being billed after the database is gone.

#A routine that works

1. A nightly logical dump with pg_dump or mysqldump, kept off the database's network. This is your real backup. See backups.
2. A snapshot before anything risky: a schema migration, a bulk delete, a major application release.
3. Delete snapshots once the change has proved itself, so they stop costing you.