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.
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.
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.
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.
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.
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.
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.
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 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.
SELECT * FROM kafka_consume('events') — positions, timestamps, keys, and contents includedWHERE value LIKE '%purchase%' works on the very bytes the sender wroteRebuilding 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.
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.
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'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