osFoundry / Platform
Change-data capture
Stream every row change out of any app database. Wire CDC into agents, channels or webhooks.
What it is
Change data capture (CDC) in osFoundry turns the database behind one of your apps into a live event stream. Instead of polling a table on a schedule and diffing the results, CDC watches the database directly and emits an event for every row that is inserted, updated, or deleted — with the changed row's data attached. Each of those change events becomes something the rest of your workspace can act on the moment it happens, rather than minutes or hours later when the next sync would have run.
The point of CDC is where those events go. In osFoundry an app database is not a sealed silo — you wire its row changes into three destinations. You can feed them to agents, so a change to a record triggers reasoning or an action instead of waiting for someone to notice. You can route them into channels, so a stream of edits shows up as live activity your chat, knowledge base, and other apps can all read. And you can forward them to webhooks, so an external system receives every change as it lands. One database, three ways out, all driven by the actual writes hitting the table rather than a copy that goes stale the instant it is made.
This matters because osFoundry is bring-your-own-key and local-first. CDC reacts to your own app's data using your own credentials, with no reseller sitting between you and the events, and the change stream stays inside the workspace you control. The result is that the numbers agents reason over and the events downstream systems receive are the real writes as they occur, not a periodic export you have to remember to refresh. It closes the gap between "the data changed" and "something responded to it."
Key capabilities
- Emit an event for every insert, update, and delete on an app database, with the changed row's data attached to each event
- Stream row changes as they land instead of polling a table on a schedule and diffing snapshots
- Wire changes into agents so a row edit can trigger reasoning or an action in near real time
- Route changes into channels so live activity is readable by chat, knowledge, and other apps — or forward them to outbound webhooks for external systems
- React to your own app data with your own keys — no reseller between you and the change stream, and the stream stays in the workspace you control
Use cases
- Product engineer: stream inserts from an app's orders table into a webhook so an external fulfillment system reacts the instant an order is written, with no polling loop to maintain
- Ops lead: route updates on a status table into a channel so the team and the agents watching that channel see state changes as live activity instead of a stale dashboard
- Automation builder: wire deletes and edits on a records table to an agent so it re-checks downstream data the moment a row changes, rather than on a fixed timer
Frequently asked questions
What is change data capture and how is it different from a scheduled sync?
Change data capture watches a database and emits an event for each row that is inserted, updated, or deleted, the moment it happens. A scheduled sync instead re-reads the whole source every few minutes and diffs it, so it misses intermediate changes and always lags by the interval. CDC in osFoundry reacts to the actual writes as they land, so there is no polling loop and no staleness window between the change and the response.
Where can I send the row changes?
Three destinations. You can feed changes to agents so a row change triggers reasoning or an action; route them into channels so the stream of edits is readable by chat, knowledge, and other apps in the workspace; and forward them to webhooks so an external system receives every change as it occurs. You can use these together — the same change stream can drive an agent and hit a webhook.
Which databases can CDC stream from, and does the data stay private?
CDC streams row changes out of an app's own database in your osFoundry workspace. Because osFoundry is bring-your-own-key and local-first, you react to your own app data with your own credentials, there is no reseller sitting between you and the change events, and the change stream stays inside the workspace you control rather than passing through a third party.