Imagine you’re running a multi-terabyte production database in Neon when you accidentally drop a critical table. Ouch. 

You notice the mistake a few minutes later, during which your high-ingestion workload continues pumping new data into the database.

How can you recover that dropped table without losing all the fresh data that’s arrived post-incident?

Neon’s superpower: Instant PITR

Enter Neon’s superpower: Instant Point-in-Time Recovery (PITR). With Neon, you can use branches to restore your database to the moment just before the table disappeared; this is instant, no matter how large the database. 

When you restore your database to just before the table disappeared, you’re actually creating a new branch rather than overwriting your current production branch. This means:

• Production stays online. Your existing “main” branch—the one missing the table—continues running unaltered. New data can keep flowing in, so there’s no disruption to ongoing workloads.
• You get a fully independent environment. The restored branch has its own dedicated compute resources. It’s equivalent to the concept of restoring to a new database instance, but much, much faster. 
• It takes 1 second—even for huge databases. Neon uses copy-on-write storage. Instead of cloning terabytes of data, the new branch references the same underlying storage until you modify something. This is what makes the recovery process nearly instantaneous, taking about one second regardless of database size.

How to use this PITR feature to restore the missing table in production? Below, we’ll outline two recovery routes you can follow, also highlighting why this process is so much faster and more efficient—especially at large scales—than the conventional restore process in RDS and other managed Postgres.

Two recovery routes 

Route 1: Keep production as is & copy the missing table from a PITR branch

This is our recommended approach if you need the data that arrived after the drop. However, if you don’t need that data (e.g. if you are working with curated historical data where new writes are not critical) then the second approach below may be a better fit.

To recover production as quickly as possible, follow these steps:

1. Identify the time of the “bad event”. Estimate the timestamp just before the table was dropped. If you’re unsure when this happened, you can use Neon’s Time Travel feature: in the production branch, you can run queries against past timestamps to pinpoint exactly when the table disappeared.
2. Run PITR to the time just before the drop. Then, use Branch Restore to create a separate branch at the exact point in time before the table was dropped. This recovered branch is instantly available and contains your dropped table. Your production branch continues running as usual.
3. Dump/copy the dropped table from the recovered branch. Connect to the new branch and export the schema and data of the missing table (e.g., using pg_dump).
4. Restore the table into your production branch. Import the table into your current production branch, which has continued ingesting data since the drop.
5. Validate & confirm. Verify that the table is restored and that all data is consistent. Your ongoing data ingestion (the inserts/updates that happened after the table drop) remains intact because you never rewound or replaced the production branch.

This method ensures that production remains online and minimizes downtime. Since the PITR process is instantaneous in Neon, you only need to wait for the missing table to be restored, rather than rolling back the entire database into a separate instance—a much slower process.

Scroll down for a more detailed comparison of Neon’s approach versus traditional restore methods in AWS RDS and other managed Postgres services.

Route 2: Switch production to the recovered branch

This approach is recommended if you don’t need the data that was ingested after the drop. It allows you to fully “rewind” your database to its pre-drop state, effectively undoing the mistake as if it never happened, and it’s very fast to do it in Neon.

To switch production to the recovered branch, follow these steps:

1. Branch at the pre-drop moment. Just like in Route 1, create a new Neon branch at the timestamp just before the table was dropped. This recovered branch is instantly available and contains your database in its exact state before the drop.
2. Swap the endpoint to the new branch. Neon has a built-in feature that allows you to swap the branch underneath an existing database endpoint. This means your production app can now point to the recovered branch without changing DB connection URLs or restarting the application: the switch is seamless.
3. Decide what to do with the post-drop data. If you don’t need the data that was written after the drop, you’re done: your database has effectively been restored to its pre-drop state. If you do need the post-drop data, you’ll need to manually merge it into the recovered branch, which can be complex depending on your workload. That’s why if you have high ingestion, we would recommend following Route 1 instead.

This approach is best suited for scenarios where you want to fully revert to a known good state and discard any post-drop changes. This may be the case for datasets that don’t require continuous ingestion. The key advantage is that Neon enables an instant transition, allowing you to simply swap branches seamlessly under the same database endpoint instead of waiting for hours for the restore to complete.

Why Neon shines at restores at scale

Let’s recap Neon’s unique advantages for recovery:

Instant PITR at any scale

With Neon, spinning up a new restored branch is immediate—even for massive databases. Whether your database is 10 GB or 100 TB, the recovery time remains the same: about one second. 

This is made possible by Neon’s copy-on-write storage model; instead of duplicating data, it simply references existing storage pages until changes are made. Traditional restore methods require creating a separate instance, recovering data from snapshots, and replaying WAL. This process is not necessary in Neon—you’re saving all that time.

Recover from an exact time, which you can verify using Time Travel

Neon retains a complete history of your database, allowing you to restore to an exact moment—whether it’s “10 minutes before a bad migration” or just before an accidental table drop. If you’re unsure of the precise recovery point, you can use Time Travel queries to inspect past database states and pinpoint when the data was lost. Your restored branch is created at the optimal moment, minimizing data loss and recovery time.

Point production to a restored branch without restarts

For cases where you want to revert to a pre-drop state entirely, Neon allows you to swap branches under an existing database endpoint. This means you can instantly point your application to the recovered branch without changing connection URLs or restarting your app, a process that would require updating configuration files and redeploying services in other managed Postgres.

Comparison vs. AWS RDS and other managed Postgres

AWS RDS Postgres	Neon
Restores the database to a separate instance by loading data from snapshots and replaying WAL	Creates a restored branch at a specified point in time using a copy-on-write mechanism
Restores take hours for multi-TB databases	Restores are instant (≈ 1 second) at any scale
Must wait for the full restore and WAL replay to complete before accessing the recovered instance (≈ hours)	Restored branch available immediately

For small databases, the difference between Neon and RDS is not drastic. Both support PITR and restoring from a pre-drop state, and for databases just a few gigabytes in size, RDS’s process is relatively fast. But as database size grows to TBs, RDS’s PITR becomes significantly slower, while Neon’s approach remains just as fast. 

The AWS RDS restore process: Why it’s slower

AWS RDS relies on automated snapshots and WAL replays for PITR. If your last snapshot was taken hours ago, RDS must:

1. Restore the full snapshot (which takes time, especially for large instances).
2. Replay all WAL logs from that snapshot to the desired recovery point.

For large, busy databases, this process can take hours before you can even begin extracting the dropped table.

Neon’s key advantage: Instant PITR

Neon eliminates these bottlenecks because:

• Neon creates a new branch at the required recovery point in seconds using copy-on-write branching, no matter how large the database is (it takes 1 second for 10 GB and for 100 TB). 
• As soon as the branch is created, you can immediately export the missing table and import it back into production.

Wrap up 

Neon is trusted in production by thousands of teams, with over 18k databases created daily. If you’re not yet a Neon user, sign up today to see why so many teams are making the switch—or reach out to us if you’d like more information or a live demo.