D1 Time Travel replaces snapshot timing with retained database history
D1 enables minute-level recovery on its new storage backend. The recovery window and backend version determine which databases can use it.
A scheduled backup leaves a gap between the last saved state and a mistaken update. The operator may know exactly when the mistake happened while still lacking a backup close to that moment. Cloudflare's July 27 D1 release notes make Time Travel available for databases using the new storage subsystem. It allows restoration to any minute within the retained history.
The retained window is 30 days on the Workers Paid plan and seven days on the Workers Free plan. Cloudflare says storage for that history and restore operations have no additional cost. These are recovery limits for the managed service, so the plan and the database backend both matter. An existing database on the legacy alpha system does not gain this capability merely because the feature has been announced.
I like SQLite because its file model keeps the database comprehensible to the application that owns it. A managed service needs an equally comprehensible account of recovery. Time Travel is useful because its contract names a recoverable interval instead of leaving an application owner to infer it from a backup schedule.
The history is a sequence of changes
Cloudflare described the mechanism in May, when Time Travel was still planned. The service retains a stream of database changes in the write-ahead log. It can reconstruct a point in time by replaying changes in sequence up to that point. July's availability note turns that planned recovery facility into a supported operation on the new backend.
The important difference from a manually initiated backup is when the history is collected. An operator does not have to predict the mistake and take a snapshot immediately before it. The recovery material already exists within the service's retained window. That directly addresses failures where the need for a backup becomes clear only after the incorrect statement has committed.
A write-ahead log is not by itself a user-facing recovery policy. The service must retain enough history and provide a way to select a recoverable state. Cloudflare's announcement supplies the policy in terms of minute-level selection and a bounded number of days. The underlying change stream explains how the service can support that policy without asking users to create each restore point.
The May article presents a missing WHERE clause on an update as an example. Such a statement can be valid SQL while expressing the wrong application action. Database execution cannot infer the intended subset of rows. Historical recovery addresses the resulting state after the application has already accepted the operation.
Choosing a state requires application knowledge
A recovery interval answers when a state may be selected. It does not tell the operator which state contains the intended application data. If a schema migration or bulk update caused the problem, the relevant point may be just before that operation. If the problem was discovered much later, identifying that point requires a history of application changes.
This is a practical consequence of point-in-time recovery. A successful restore can reproduce a past database state without establishing that it is the right state for every business operation. Valid writes made after the mistake may also matter. Reconstructing those intended changes is an application problem that the announcement does not claim to solve automatically.
The minute-level description also sets expectations about precision. It should not be paraphrased as a promise of arbitrary subsecond selection. The May article showed a proposed interface using timestamps and transaction identifiers, but it explicitly allowed for API changes. The July release note establishes availability and retention without making that earlier example the final command contract.
For that reason, the durable part of the announcement is the recovery model. A timestamp represents a requested historical state within a retained interval. The application owner still needs to understand when harmful and legitimate changes occurred relative to that state.
The backend version determines availability
July 27 also changes which storage subsystem new databases use by default. Databases created through the dashboard and Wrangler, as of version 3.4.0, now use the new backend. Cloudflare's release note identifies this as a separate change alongside Time Travel availability.
The documented inspection command is small and does not perform a restore.
wrangler d1 info YOUR_DATABASE
In the release's terminology, a database reporting version: beta uses the new backend and supports Time Travel. A database reporting version: alpha uses the legacy backend. That version field is an operational discriminator, not a statement about which SQL syntax the application happens to use.
The new default applies to database creation. It should not be read as a claim that every existing database has been migrated. Cloudflare's May backend announcement described export and import as the way existing users could move data into a new database using the experimental system. A changed creation default and an existing database's storage implementation are different facts.
This is especially relevant when the application has several databases. The fact that one newly created database supports the recovery API does not establish the same for an older database in the account. Checking the version identifies which recovery model applies to the particular data involved.
Snapshot backups remain relevant to legacy databases
The July note says Time Travel replaces snapshot-based backups for databases on the new subsystem. Legacy alpha databases continue to have their older recovery mechanism. Documentation or procedures written for one backend therefore need to state which database type they describe.
My preference is for the recovery procedure to identify the database before discussing the restore action. The same application can retain its SQL while its managed storage capabilities change. Backend identity is consequently part of the recovery contract, even though it is usually less visible than a table or query.
The free and paid retention windows introduce another concrete boundary. A state outside the relevant window is not included in the announced Time Travel guarantee. A requirement for longer retention needs its own arrangement. The availability of recent historical reconstruction does not establish an archive of every previous database state.
For databases on the new backend, the operational improvement is specific. The service retains the change history needed to reconstruct recent states, so recovery need not coincide with a manually selected snapshot time. The application can select a minute within its plan's window after identifying the operation that made the data incorrect.