Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.eventdbx.com/llms.txt

Use this file to discover all available pages before exploring further.

EventDBX is intentionally opinionated about append-only storage yet lenient everywhere else. Domains, schema modes, and plugin payload modes form building blocks you can rearrange without touching the core event log.

​
Carve up work with domains

Use domains whenever a team, product surface, or environment needs its own truth: 
dbx checkout payments-prod --create   # create if missing, then activate
dbx checkout payments-dev --create    # spin up an isolated dev domain
dbx status                            # confirm active domain + config
Each domain keeps its own RocksDB store, Merkle trees, replication offsets, and plugin queues. Teams can experiment safely by creating *-dev domains that reuse only the schemas they trust.

​
Switch domains with dbx checkout

dbx checkout activates a domain (and can create or delete it) without touching other domains:
  • dbx checkout <name> --create to spin up a new domain for experiments, CQRS bounded contexts, or per-environment isolation.
  • --delete [--force] to remove a domain deliberately; use when retiring experiments.
  • --remote <host[:port]> --token <token> [--remote-tenant <tenant>] to bind a domain to a remote control socket, useful when your write node lives elsewhere.
This keeps iteration friction low—you can hop between domains or point a domain at a remote daemon without rebuilding schemas or replaying history.

​
Evolve schemas gradually

Start in a permissive validation mode while schemas evolve, then restart the daemon with a stricter mode once shapes settle (e.g., dbx start --restrict=strict). 
dbx schema create person
dbx schema field person first_name --type text --required
dbx schema activate person --version <hash>
EventDBX never mutates historical payloads. Instead, new columns surface through snapshots and plugins once they appear often enough. Re-snapshotting an aggregate with dbx aggregate snapshot <aggregate> <id> lets you adopt the updated shape without replaying the full stream.

​
Route only the slices you need

Plugins choose the minimal payload per domain when you run dbx plugin config <type> … --payload <mode>. Modes include all (default), event-only, state-only, schema-only, event-and-schema, and extensions-only (clears payload but keeps metadata/extensions). For process plugins, add --emit-events=false if you want the worker supervised without enqueuing jobs. 
dbx plugin config http billing --endpoint https://billing.internal/hooks --payload state-only
Because payloads are set per plugin, you can bolt on new read models without modifying the write path or exposing data they do not need.

​
Sample workflow

  1. Create an experiment domain (payments-fx-dev) for foreign-exchange work.
  2. Copy the core schema and relax validation on new FX fields.
  3. Attach a log plugin that mirrors only FX aggregates for analysts.
  4. Once the feature stabilizes, promote the schema to payments-prod and rehydrate downstream stores by replaying the FX events.
This pattern lets you iterate quickly while preserving EventDBX’s guarantees around durability and integrity.