This is a different feature than PiTR. We have both. They serve different needs.

that's correct.

That is a different feature (although a cool one). They provide the ability to run a query as of a point in time. We are moving the database backward in time (which matters for running applications)

Also, generally DDL statements like DROP TABLE typically autocommit.

You can also clone the database volume in Aurora and then just backtrack one of the volumes. That should help you ensure you have a version available for forensic analysis.

You're right - it is a lot faster. That's because we don't change any data blocks. we just mark a portion of the log to be ignored.

That's not correct. We made a change to mark portions of our log-structured storage as though they should not have occurred. It is a totally different approach than point-in-time restore.

As the previous commentor said, this isn't point in time restore or a change in our processes. It is a change to our database and storage engine to mark regions of log-structured storage as if they did not occur. That's why we can complete a Backtrack in a few seconds - we're just moving some pointers around and restarting the database.

We've had point in time restore for quite some time. Backtrack is different. It moves you to a different point using the same instance. Since we don't do destructive writes to blocks (it is log-structured storage), we can simply mark a portion of the log as "ignored". It is a server feature, not a UI enhancement.

no, we don't perform destructive writes so we are able to simply mark a region of the log as to be skipped. this approach also allows us to move back and forth within the time domain even after a backtrack.