Changefeeds are how you ask SurrealDB for a history of writes to a table (or database) so you can replay them elsewhere: search indexes, warehouses, cache warmers, or any system that needs to catch up after downtime.
You define how long changes are retained when you set up the feed by adding a duration like 3d or 100h. Changes are then read with the SHOW statement.
What you need first
Before SHOW CHANGES returns anything useful, the table or database must opt in with a CHANGEFEED definition (duration, scope). Changefeeds are usually defined using a DEFINE TABLE statement, but can be defined on the entire database if desired via DEFINE DATABASE.
Replaying from a point in time or a versionstamp
A typical flow is:
Note when you last processed changes (a datetime) or where you stopped (a versionstamp).
Ask for everything since that marker, optionally with a limit so you page through large backlogs.
The SHOW statement reference spells out the full syntax. In practice you are choosing: “give me the next batch of mutations after this cursor.”
If the datetime is after the changefeed was created and lines up with your retention window, you get a list of entries, each with changes and a versionstamp (where you are in the log). How each mutation is encoded depends on your DEFINE TABLE ... CHANGEFEED options; when differences are stored (INCLUDE ORIGINAL), an update to an existing row carries a reverse diff from the current state to the state immediately before that write. The SHOW reference covers this in full. The following shape is representative: