By Harish Shenoy, Data & AI Solutions Architect at Databricks
For the last decade, the disaster recovery conversation has been about backups. How often do you back up? Where are they stored? Are they immutable? That conversation is now ending. Backups have now become table stakes: automated, continuous, and cheap. In 2027, the question every team will be: how fast can you restore?
I predict three shifts that will define database disaster recovery in 2027.
Prediction 1: “Time to restore” joins RPO and RTO as a headline DR metric.
RPO and RTO have been the standard vocabulary of disaster recovery for years. But both are planning numbers. They describe what the business can tolerate, not what the system can actually do. In 2027, “time to restore” will appear on DR dashboards alongside them, and it will be the number executives ask about first.
RPO tells you how much data you might lose. RTO tells you how long the business waits. Neither tells you whether your team has ever actually restored this database, at this size, under pressure. Time to restore is a measured number, not a planned one, and measured numbers are harder to fake. I expect DR runbooks to be rewritten around it: every critical database gets a tested restore time, published internally, reviewed quarterly.
Prediction 2: Automated restore testing becomes table stakes.
An untested backup is not a backup. It is a hope. Most teams know this and still test restores manually, infrequently, or not at all, because a restore test on a production scale database is expensive: you need a full copy of the data, the compute to run it, and the engineering time to babysit it.
That excuse is expiring. Copy-on-write database branching has made it possible to spin up a full, writable copy of a production database in seconds, at a fraction of the storage cost. When a restore test costs minutes instead of days, there is no reason it should not run automatically, on a schedule, with alerts when it fails. In 2027, auditors and customers will start asking for restore-test evidence the same way they ask for backup logs today. Teams that cannot produce it will be treated the way teams without backups were treated five years ago.
Prediction 3: Restore workflows merge into CI/CD.
The most interesting change will be where restore testing happens. It will move out of the once-a-quarter DR drill and into the everyday engineering workflow. Every pull request will be able to spin up an isolated copy of the production database, run migrations and tests against it, and destroy it on merge. I have been building exactly this kind of workflow in the open, and the pattern is clear: when branching a database is as cheap as branching code, the database stops being the fragile part of the pipeline.
This changes what “disaster recovery” means operationally. Recovery stops being a separate discipline practiced by a separate team. It becomes a property of the system, exercised constantly by the same automation that ships code.
Why this matters now: AI workloads raise the stakes.
There is a forcing function behind all of this. AI agents and retrieval systems depend on databases being correct and current. A vector index that is a day stale does not just degrade an application; it silently corrupts every answer the system produces. When the database is the memory of the AI system, an unrestorable or slow-to-restore database is not an infrastructure problem. It is a product outage with no workaround.
In 2027, the teams that treat restore speed as a first-class metric will be the ones whose AI systems survive their first real incident.
Why I see it this way
I have spent 16 years in database technologies, and I have watched the same pattern repeat in every era. At AWS, I led the program for the launch of Amazon Aurora Limitless, and I wrote about disaster recovery architectures for the AWS Database Blog. In every customer engagement, the teams that survived incidents were never the ones with the most frequent backups. They were the ones that had practiced restoring. Now at Databricks, working with customers on Lakebase and the lakehouse, I see the same truth operating at larger scale: the database is no longer just storage. It is the memory of the AI system, and memory that cannot be restored quickly is a liability. I have been building database branching workflows in the open because I believe restore testing should be as routine as running a test suite. In 2027, it will be.
