Skip to main content
Schema enforcement in EventDBX is opt-in and gradual. Start flexible, codify columns as you learn, then tighten validation once the model hardens. Schemas live in schemas.json (per domain/tenant), drive validation for every write, and include snapshot thresholds so materialisation stays predictable.

​
What schemas control

  • Field allow-lists per event (which fields each event may set).
  • Column types and rules (required/optional, ranges, regexes, formats, nested properties).
  • Snapshot cadence per aggregate (snapshot_threshold) plus field visibility (schema hide).
  • Versioning and history via publish/activate so changes stay auditable.

​
Define fields and events

  • Supported column types: integer, float, decimal(precision,scale), boolean, text, timestamp, date, json, binary, object.
  • Allow fields per event: dbx schema alter <aggregate> <event> --add <field,...> (or --remove/--set/--clear).
  • Shape fields: dbx schema field <aggregate> <field> --type <type> [--required|--not-required] [--format ...] [--length-min ... --length-max ...] [--range-min ... --range-max ...] [--regex ...] [--contains ...] [--properties <json>].
  • Snapshot cadence belongs in the schema: dbx schema create ... --snapshot-threshold <count> and dbx schema alter ... --snapshot-threshold <count> override the global default.
Deep dive → Column definition

​
Validation and formats

  • Inline rules via dbx schema field: required/optional, contains/does_not_contain, regex (repeatable), length, numeric/date range, nested properties for objects.
  • Apply semantic formats with --format <email|url|credit_card|country_code|iso_8601|wgs_84|camel_case|snake_case|kebab_case|pascal_case|upper_case_snake_case>; drop them with --clear-format.
  • Hide sensitive fields from aggregate detail responses: dbx schema hide --aggregate <type> --field <name>.
  • Test in restrict=default, then enforce in restrict=strict once confident.
Deep dive → Rules · Deep dive → Field formats

​
Versioning workflow

Schemas are versioned artifacts. Edit via the CLI or by touching schemas.json, then:
  1. dbx schema publish – snapshot the current schema (per tenant/domain).
  2. dbx schema activate --version <id> – make a published version active.
  3. dbx schema reload – force the daemon to pick up the active version if needed.
Inspection tools:
  • dbx schema history – list published versions with who/when/why.
  • dbx schema show --version <id> – view a specific version.
  • dbx schema diff --from <id> --to <id> – compare versions (patch/unified/split).
  • dbx schema rollback --version <id> – restore a prior version as active.
Validation helpers:
  • dbx schema validate <aggregate> --event <name> --payload <json> – test payloads against the active schema.
  • dbx schema list – inspect current aggregates and snapshot thresholds.
Even when editing schemas.json directly, publish/activate to keep history auditable and nodes consistent.