If someone accidentally drops a table, runs a bad UPDATE, or deletes the wrong rows, YugabyteDB gives you two very powerful recovery-oriented features: Point-in-Time Recovery (PITR) and Instant Database Cloning.
At first glance, they sound similar because both let you access an earlier state of the database. But operationally, they behave very differently.
● PITR rewinds the existing live database to an earlier point in time.
● Instant Database Cloning creates a new writable database from an earlier point in time.
● When CDC is involved, that difference matters a lot, because CDC expects a forward-moving stream of changes.
What is CDC?
CDC (Change Data Capture) is the mechanism that streams row-level changes (inserts, updates, and deletes) from YugabyteDB to downstream systems. Depending on the integration path, that may mean Kafka, Debezium, another service, or a custom consumer. The key idea is that downstream systems consume a forward-moving sequence of changes from the source database.
You can think of CDC as:
- “Tell downstream systems what changed in the database, in the order those changes happened.”
That forward-only expectation is exactly why PITR needs special care when CDC is enabled.
What is PITR?
Point-in-Time Recovery (PITR) allows you to restore the state of a database or keyspace to a specific earlier timestamp within a configured retention window. YugabyteDB positions PITR as a fast way to recover from user or application mistakes without having to do a traditional full backup restore.
You can think of PITR as:
- “Take my current database and make it look like it did at 10:14:59 AM.”
That is extremely powerful for recovery, but it is also an in-place rewind of the live database. Any good changes that happened after that timestamp are also rolled back.
What is Instant Database Cloning?
Instant Database Cloning lets you create a zero-copy, independent, writable clone of a database, either as of “now” or as of a point in the recent past within the configured retention period. When the clone is first created, it shares the same underlying data files as the original database. As new writes happen, the clone stores its own changes separately. This is fast and efficient because the clone is initially zero-copy and then diverges through separate delta files.
You can think of cloning as:
- “Create a brand new database that looks exactly like production did at 10:14:59 AM.”
See: Instant Database Cloning (Zero-Copy PITR in Seconds)
The core operational difference
This is the single most important distinction:
That means PITR is a restore of production, while cloning is more like a branch or parallel copy of production from a chosen timestamp.
Why PITR and CDC are tricky together
This is where things get interesting.
The current PITR docs explicitly say that using PITR and CDC together is currently not supported, and they point to GitHub issue #12773 as the tracking issue.
Why does this limitation exist?
Because CDC depends on a forward-moving sequence of changes, but PITR restores database state through the recovery path rather than as normal forward CDC-visible row changes. The GitHub issue explains the underlying problem very directly: CDC reads changes from the WAL and IntentDB, but when a snapshot is restored, the restored data does not go through that same CDC-visible path, so CDC cannot simply interpret the rewind as ordinary forward progress.
So the practical takeaway is:
● PITR can recover the database state.
● But PITR is not a seamless continuation point for existing CDC streams.
● After restore, you should plan to create new CDC streams and resume from the restored point.
Why Instant Database Cloning fits CDC much better
Cloning is much friendlier operationally because it does not roll production backward.
Instead:
● the original production database keeps running
● its CDC stream keeps moving forward
● downstream consumers do not need to reconcile a backward jump in source data
● if you want CDC on the clone, you can treat it as a separate database and create separate streams there as needed
That makes cloning a much safer option when the real goal is not “rewind everything,” but rather “recover specific data without disrupting live downstream change capture.”
The best pattern: clone + patch
For many real-world recovery events, the strongest operational pattern is this:
1. Identify a timestamp just before the bad change.
2. Create an instant clone from that timestamp.
3. Inspect the clone and find the rows or values you want back.
4. Apply targeted
INSERTorUPDATEstatements into production.5. Let production CDC capture those corrective changes naturally as normal forward events.
This gives you a very strong combination of features:
● historical access to the good state
● no rewind of production
● no forced break in normal production CDC flow
● surgical recovery instead of blunt rollback
Example: bad delete at 10:15 AM
Suppose a bad DELETE runs at 10:15 AM.
Option 1: PITR production to 10:14:59 AM
This restores the live database back to just before the bad delete. That may bring the lost rows back, but it also removes all good changes made after 10:14:59 AM. If CDC was configured, you should not assume the old streams can continue as-is; plan to create new streams after restore.
Option 2: Clone production as of 10:14:59 AM
This leaves production online. You inspect the clone, export the deleted rows, and reinsert them into production. Those corrective inserts happen normally on the live database, so CDC can emit them as standard forward changes.
For selective recovery, Option 2 is usually the cleaner operational story.
When to use which
Use PITR when:
● the entire live database really needs to be rolled back
● the error is broad enough that a full rewind is acceptable
● you are prepared to recreate CDC streams afterward if CDC is involved
Use Instant Database Cloning when:
● you want to inspect historical data without touching production
● you need to recover only specific rows or objects
● you want a safe recovery or forensic sandbox
● you want to preserve production continuity while fixing data surgically
📌 Limitations
The PITR docs list several limitations, but for this article the most relevant one is the CDC limitation:
- ⚠️ PITR and CDC cannot currently be used together.
What this means in practice is that YugabyteDB cannot automatically reconcile existing CDC streams after a PITR restore.
- ● After the restore completes, you should create new CDC streams and resume consumption from that point.
- ● Existing CDC streams should not be reused, as they may no longer reflect a valid forward progression of changes.
Final takeaway
PITR and Instant Database Cloning both let you work with the past, but they are not interchangeable.
● PITR is a rewind of the live database.
● Instant Database Cloning is a separate writable copy from a past moment.
● CDC prefers forward progress, which is why cloning usually fits better operationally when downstream streaming matters.
So if your goal is:
- “Recover data safely without disrupting production CDC more than necessary”
the best pattern is usually:
- clone from a good timestamp → inspect/extract good data → patch production forward.
PITR is best when you truly need to rewind the live database.
Instant Database Cloning is often the better fit when you need to recover data selectively, investigate historical state, or preserve the normal forward flow that CDC-based integrations depend on.
Have Fun!