Committed captures every change from Postgres, MySQL and SQL Server and syncs it into the tables you actually read, all in one process: the log, the source, and the sink. No Kafka, no Debezium, no Connect cluster. The hosted service is run by the team that builds the database.
Talk to an engineer →{
"phase": "streaming",
"snapshotProgress": [
{ "table": "public.orders", "complete": true }
],
"position": "0/1A2B3C8",
"lag": 0,
"caughtUp": true
}This is what an ingestable reports. lag is read in bytes from the replication slot, so caughtUp means the slot is drained, not that nothing has errored lately.
An ingestable captures; a syncable delivers. If you've run Kafka Connect, those are your source and sink connectors, except they run in the same binary as the log.
The task says RUNNING. Nothing is flowing. You find out days later because a table stopped changing.
A syncable that cannot make progress stalls visibly rather than skipping data on a guess. A worker that hits a systematic fault parks, and stays parked until you act. One call to the cluster status endpoint answers "is anything parked anywhere?" across every node.
Stuck syncables runbook →An error downstream, and the connector keeps committing offsets while the rows reach neither the table nor the dead-letter queue.
Every write a syncable makes is a keyed, idempotent upsert, so re-applying is safe and the last write wins. A transient failure downstream is retried until it clears, never skipped on a guess, and a systematic fault parks the worker instead of dead-lettering a whole topic. A syncable can be a mirror or a read model folding several topics into one, and either way it is built from the log: a wrong table is rebuilt from the log, never wrong for longer than a replay, and the source database is never touched to fix it.
Stuck syncables: dead letters and parking →One brief outage, and the fix is a ten-hour snapshot against production.
A restart mid-snapshot resumes from a per-table cursor instead of starting over. And because every captured change is already in the log, rebuilding a table replays from the log instead of re-snapshotting the source database.
CDC setup: snapshot and resume →The failure lands on the database, not the pipeline, and it lands at 3am.
Lag is read in bytes from the replication slot itself, so you see the slot's real cost rather than a proxy for it. Delete an ingestable through the API and its slot and publication are dropped with it.
Lag and the slot's disk cost →A routine migration, and the values from the backfill quietly never arrive.
A changed column set is rejected explicitly, never silently ignored. The new table shape replays from the log, and because the log is permanent, replay is cheap.
Read models: schema evolution →Connectors, offsets, schema history, heartbeats, replay, resnapshotting, recovery. Each one a thing that breaks.
Log, source, and sink in one binary. Upgrades roll node by node with no downtime, and roll back the same way. We run it, so the second job is ours.
Rolling upgrades →Committed is built by Riser Tech, Inc. and led by founder Phil Borlin, the engineer behind the Committed project. When you book a call, scope a deployment, or get onboarded, you are talking to the people who write the database.
You talk to an engineer, not a demo script. We dig into your event model, your query stores, and whether Committed is actually the right fit for your system.
Cluster sizing, sync targets, and the migration path from your current pipeline, all scoped with you before anything is provisioned.
Provisioning, replication, backups, monitoring, upgrades. Onboarding is white-glove: an engineer who builds the database sets up your cluster and stays reachable.
Under active development. See the releases.
The ingestable re-snapshots the source, and keyed tables reconcile against it: rows that survived are re-stamped in place, rows deleted while nothing was watching are swept. No duplicates, and no manual diff.
A config that changes a table's column set is rejected with a clear error rather than silently no-op'd. You replace the syncable and the new shape replays from the log. Nothing is altered underneath a live consumer.
Every change is applied at least once through keyed, idempotent syncables, so re-applying is safe and the last write wins. A transient failure downstream is retried until it clears rather than skipped, so a stall is always visible and never a silent gap.
Yes. Each syncable can be rebuilt on its own: drop and replay from the log, under the same name, without touching the others or the source database.
On a cluster we run for you in the cloud. Deployment details, including region and isolation, are scoped with you before anything is provisioned.
Backups are part of the service, not an add-on. And because Committed is an append-only log, the tables it syncs can always be rebuilt from the log itself.
A small engineering team, and only for operating your cluster. We'll walk through the specifics with you before you commit to anything.
The engine under the service is open source. Your data lives in a system you could run yourself, so a bet on us is not a bet you can't unwind.