Database Application Disaster Recovery Made Easy

We’re excited to announce a new feature for DBOS Cloud: point-in-time database and application recovery. 

Disasters Happen

Disasters may occur because of a bad software patch. It may also happen because of a successful ransomware attack or because something bad happened in your internal operating environment, such as someone inadvertently typing “rm *”.  Regardless of the cause, the consequences can be catastrophic.

If you’ve built your back-end with DBOS Transact and run it on DBOS Cloud, then no problem because DBOS makes it a snap to restore your application and database to a specific point in time…right down to a specific transaction.

This is enabled by the fact that DBOS automatically records all application and operating environment state–and every state change (i.e., an event log) in a DBMS. You can keep this “event log” as long as you wish (or are willing to pay for the space). This record, combined with DBOS time travel and automatic, periodic checkpointing of the environment enables the following disaster recovery capabilities:

Point-in-time Database Recovery: Restore your database to its exact state at any past point in time within your data retention period (24 hours for free users). If a misbehaving application or faulty migration deletes crucial data, you can recover it in minutes. This restoration includes all DBOS system and provenance data for your application, so capabilities like time travel will work normally on the recovered database.

Point-in-time Application Recovery: Restore your application to its exact version at any past point in time. If a newly deployed application version is causing an incident, you can restore the previous version in seconds.

How DBOS Point-in-Time Recovery Works

Under the hood, DBOS leverages Postgres point-in-time recovery. When you restore a database, DBOS starts a new database instance from a backup, then rolls it forward using the database event logs (archived by DBOS) until it reaches the time you specify.

After the new database instance is ready, you can redeploy your applications to it. You can deploy a new application version or restore the version that was running originally. As part of the redeployment process, to avoid duplicating finished operations, DBOS Cloud moves in-progress workflows to a “dead letter queue” so you can choose whether to resume them.

Learn More

To learn more about point-in-time recovery in DBOS, check out the documentation.

Insights

Recent articles

The latest in durable execution, AI workflows & more.

Product news
Jun 18, 2026

What's New in DBOS - June 2026

New in DBOS: RBAC support, OpenMetrics, Bulk Workflow forking, Google ADK plugin, and more.
Qian Li
DBOS Architecture
Jun 15, 2026

Just Co-Locate Data in Postgres

When workflow metadata and application data live in the same Postgres database, they can be updated in the same database transaction, which simplifies problems like workflow task idempotency and atomicity.
Peter Kraft
Qian Li
How To
Jun 2, 2026

Just Use Postgres for Task Queues

Lessons learned from scaling Postgres-backed durable queues for tens of billions of workflows per month.
Qian Li
Peter Kraft

Database Application Disaster Recovery Made Easy

We’re excited to announce a new feature for DBOS Cloud: point-in-time database and application recovery. 

Disasters Happen

Disasters may occur because of a bad software patch. It may also happen because of a successful ransomware attack or because something bad happened in your internal operating environment, such as someone inadvertently typing “rm *”.  Regardless of the cause, the consequences can be catastrophic.

If you’ve built your back-end with DBOS Transact and run it on DBOS Cloud, then no problem because DBOS makes it a snap to restore your application and database to a specific point in time…right down to a specific transaction.

This is enabled by the fact that DBOS automatically records all application and operating environment state–and every state change (i.e., an event log) in a DBMS. You can keep this “event log” as long as you wish (or are willing to pay for the space). This record, combined with DBOS time travel and automatic, periodic checkpointing of the environment enables the following disaster recovery capabilities:

Point-in-time Database Recovery: Restore your database to its exact state at any past point in time within your data retention period (24 hours for free users). If a misbehaving application or faulty migration deletes crucial data, you can recover it in minutes. This restoration includes all DBOS system and provenance data for your application, so capabilities like time travel will work normally on the recovered database.

Point-in-time Application Recovery: Restore your application to its exact version at any past point in time. If a newly deployed application version is causing an incident, you can restore the previous version in seconds.

How DBOS Point-in-Time Recovery Works

Under the hood, DBOS leverages Postgres point-in-time recovery. When you restore a database, DBOS starts a new database instance from a backup, then rolls it forward using the database event logs (archived by DBOS) until it reaches the time you specify.

After the new database instance is ready, you can redeploy your applications to it. You can deploy a new application version or restore the version that was running originally. As part of the redeployment process, to avoid duplicating finished operations, DBOS Cloud moves in-progress workflows to a “dead letter queue” so you can choose whether to resume them.

Learn More

To learn more about point-in-time recovery in DBOS, check out the documentation.