Skip to main content
EventDBX is an append-only, event-sourced write database that keeps your aggregates verifiable, replicas aligned, and downstream systems hydrated without touching the write path. Instead of hand-building bespoke schemas up front, you capture events, validate them with Merkle-backed integrity checks, and fan them out through plugins that specialize in the read side.

​
Core Motivations

EventDBX succeeds when it:
  • Enables developers to quickly build applications without hand-designing schemas or wrestling with ORMs; schemas stay an afterthought you tighten later.
  • Enforces task-based thinking over CRUD. Start from what customers tell you and persist what they know instead of designing tables first and training users to fit them; workflows stay aligned with intent.
  • Provides a trustworthy source of truth for other systems. The append-only event log plus Merkle verification prevents silent edits—no administrator can tweak a column without leaving evidence—so downstream systems can trust replicated histories instead of worrying about invisible hotfixes.
The CLI binary is dbx; older releases exposed an eventdbx alias, but dbx is the canonical entry point.

​
Architecture at a glance

EventDBX follows the CQRS first principle: isolate the write path (capture + validate + append) from read responsibilities (materialization, search, analytics) so each side can scale and evolve independently. EventDBX is deliberately write-path-first—plugins own the read models so writes stay fast, append-only, and verifiable.
  1. Events in, state verified – dbx aggregate apply validates payloads (when restriction is enabled), merges them into the aggregate snapshot, and appends the event. Per-aggregate Merkle trees detect tampering immediately.
  2. Plugins out – every committed event flows into a durable job queue. TCP/HTTP/log/process emitters decide which payload slices they care about, while queue backoff keeps delivery reliable.
  3. Domains & replication – dbx checkout creates isolated storage roots per bounded context, and dbx push/pull/watch mirror those roots across environments with concurrency controls.

​
Where EventDBX fits

EventDBX lives on the write side: only trusted services send commands, and plugins keep read models fresh. End users never touch EventDBX directly—they hit the downstream systems that plugins maintain.
The diagram shows commands flowing into EventDBX, jobs entering the plugin queue, and fan-out into read models that front the user-facing APIs.

​
Choose your next step

Spin it up

Follow the CLI quickstart to start the daemon, define schemas, and append your first events.

Understand the surface area

Explore built-in capabilities—immutability, encryption, restriction modes, performance, and column types.

Operate & integrate

Run EventDBX under Docker, issue tokens, connect TypeScript clients, and schedule replication jobs.

​
Performance snapshot

EventDBX keeps throughput flat even as datasets grow past 50M records (~100 GB of storage) thanks to RocksDB batching and hot-aggregate caching.
EngineThroughput (ops/s)Latency (µs)Notes
EventDBX1 400 – 2 0000.5 – 0.8Append-only core plus caching keeps latency sub-microsecond.
PostgreSQL 151 000 – 1 9000.6 – 1.0Strong baseline, heavier planner/WAL overhead.
MongoDB 7400 – 1 0001.5 – 2.5Flexible JSON store with higher serialization cost.
SQL Server 202250 – 1805 – 20Drops quickly past 100 K ops because of locking + B-trees.
Benchmarks come from the eventdbx-perf suite (Dockerized backends, single-threaded clients, datasets up to 50M records).