Live events, inside
the database itself.
Nearly every serious data operation runs Kafka — the industry system for streaming live events — next to several databases, then pays to shuttle copies between them. SynergyDB already spoke the databases' languages, so it learned Kafka's too. The result: the moment an event arrives it is already stored, already safe, and already searchable — the event and the database record are the same bytes in the same engine.
Standard Kafka tools, no asterisks
This isn't a "Kafka-inspired" look-alike — it speaks Kafka's actual connection language, verified against the two client-software families that dominate real-world production use.
🔌Real tools connect
The same Kafka client software production systems already run — modern and classic alike — sends events, reads them back, and tracks its place in the feed with default settings, no tweaks.
🧾No accidental duplicates
If a sender loses its connection and retries, the engine recognizes the repeat and stores the event exactly once — verified end to end, with zero duplicates delivered.
👥Work that shares itself
The genuinely hard part: multiple readers join as a team, the event feed is split among them with no overlap, and when one reader drops out, the others take over its share automatically.
🧩Feeds that scale out
Each event feed can be split into parallel lanes so heavy traffic spreads across many readers at once — the foundation the automatic work-sharing divides up.
🔐Sign-in required
Senders and readers log in through the same shared credential system every other part of the engine uses — and when a login is required, an unauthenticated connection gets nothing at all.
💾Durable by construction
Event feeds are written to disk the way tables are, not held in a memory buffer. Kill the server, restart it, and a fresh reader gets every message back — each reader's bookmark survives too.
The event log is a table
The conventional stack is a federation of separate systems: an event server here, a format catalog there, connector software shuttling copies into a reporting database. SynergyDB collapses the whole pipeline, because the event stream and the database share one storage layer.
- Send three events with a standard Kafka tool…
- …then read them back as ordinary database rows with
SELECT * FROM kafka_consume('events')— positions, timestamps, keys, and contents included - Filter the live feed with an everyday query —
WHERE value LIKE '%purchase%'works on the very bytes the sender wrote - No connector, no copy, no delay between "event happened" and "event shows up in a report"
Why competitors can't follow
Rebuilding Kafka's interface proves the interface can be rebuilt. But an event system bolted next to a database is still two systems with a copying seam between them. Making the event stream and the business records the same engine, the same all-or-nothing saves, the same security is a structural property — you either design for it from day one or you don't have it.
The event-format catalog, built in
Teams keep their event formats consistent with a shared catalog — usually Confluent's Schema Registry, which is where Kafka lock-in actually lives. SynergyDB includes a compatible catalog: register a format, keep its version history, look it up by number, and configure it per subject — answering with the same responses the original gives.
🧬Proven end to end
The real Confluent tooling registers an event format, packs a record with it, sends the record through SynergyDB's event stream, then looks the format back up from SynergyDB's catalog and unpacks it perfectly — a complete round trip on one engine.
🔍The catalog is searchable too
The catalog's contents are stored as ordinary database tables — so the rules governing your event formats can be audited and reported on with plain queries, the same property the events themselves have.
Honest scope: this is built for consolidation — the mid-sized team running one oversized Kafka cluster next to three databases — and for embedding inside products, not for displacing a fifty-server hyperscale deployment. Within that lane it is feature-complete for real workloads.
Speaks Kafka's languageModern + classic clientsNo duplicate eventsAutomatic work sharingAuthenticated accessFormat catalogStandard event packagingSearch events with SQL