One log, every consumer at its own offset.
Alarms, notifications and feeds are planned as consumers of the write-ahead log that already exists, not as a second system. The event operators are in the plan language; the bus itself is not built.
Planned, not built Planned
| Phase | P6, with search, vectors and graph |
|---|---|
| Benchmark | OpenMessaging Benchmark |
| Compared with | Apache Kafka, Redpanda |
| Gate | durable replay at parity; lower p99 on one node, measured on the dedicated benchmark host |
Planned, not built. Nothing on this page exists as running code. The specification and the roadmap say what it will be and how it will be measured; no number will be published for it until it is measured on a dedicated benchmark host against the named systems.
What the specification already says
These items are written down in the architecture specification and the plan language, reviewed, and will be built as written or revised in the open.
The WAL is the source of truth
Every durable change is one log record carrying tenant, collection, key, before and after image, schema and policy version, transaction, commit time, idempotency key and actor.
PlannedConsumers with durable offsets
Replication, change capture, secondary indexes, search and vector indexes, cache invalidation, the audit chain, the event bus and feed builders each read the stream at their own offset. Derived state may lag but is always rebuildable.
PlannedEvents are sinks
An emitted event leaves the trust boundary, so the plan language treats EMIT_EVENT as a sink: security operators cannot be moved past it, and a long plan is rechecked against the policy version before it emits.
PlannedIdempotent emit
An emit is idempotent only when it carries a key; a replayed key returns the original outcome.
PlannedLISTEN / NOTIFY
PostgreSQL's LISTEN and NOTIFY are mapped to the event bus in the same phase; until then they fail with 0A000.
PlannedOperators behind the same verifier
The plan language that every SQL statement compiles to already lists these operators. When the engine arrives, it arrives behind the check that tenant isolation and access filters are applied on every data access.
| Operator | What it is specified to do |
|---|---|
EMIT | Publish rows to a topic; a sink in the security typing. |
SUBSCRIBE | Receive from a topic under the subscriber's identity and tenant. |
CDC_EMIT | Change capture from the log for a collection. |
One security model. The roadmap's rule is that every read, whatever the engine, compiles to the plan language and passes the verifier. No side door for a new engine.
What carries this workload now
Built parts that serve the need until the engine exists, and the parts that do not exist yet.
Write-ahead log with group commit
Built. Checksummed, chained records; one fdatasync covers the batch; 19 243 durable writes per second at 32 clients on the development host.
BuiltAppend-only event tables
Columnar collections reject duplicate keys and store events compactly, which is where event history lives until the bus exists.
BuiltSubscriptions, replay, topics
Not built. There is no way today to subscribe to changes or replay the log from a client.
PlannedStraight answers
Can my application get change events from UltraFabric today?
No. The log exists and is replayed on recovery, but there is no subscription, topic or change-capture endpoint yet. That is the P6 phase.
Why build the bus on the write-ahead log?
So that an event and the row it describes come from the same durable record, and a consumer that falls behind can rebuild from the log plus base data instead of from a second store that may disagree.
Follow the gate, not the promise.
The status page lists each phase, its gate and the measurement behind it, and the updates page records each step as it lands.