Event Sourcing with Chronacta
Chronacta — an event store
Event Sourcing keeps the history of meaningful changes as the source of truth, so current state can be rebuilt, inspected, and replayed. You can implement that yourself with SQL or application code, or use a specialized database such as Chronacta or KurrentDB. DDDesigner has built-in Chronacta support: an event-sourced model can produce working integration files.
What Chronacta is
Chronacta is a dedicated event store. It keeps the history of changes in an immutable log organized into streams and exposes a network API for appending, reading, subscriptions, projections, and administration.
Unlike a database that keeps only current state, Chronacta preserves the path that led to the result. That makes history available for audit, replay, and state recovery after failures or migrations.
- Not a relational database — no SQL JOINs or arbitrary row UPDATE
- Not a drop-in Kafka/NATS replacement — Chronacta is a durable versioned log; brokers still handle message delivery
- Not a CRUD store of current state — current state is derived from event history
Event Sourcing vs CRUD
In a CRUD model you overwrite the current row; previous values disappear unless you add a separate audit trail. In Event Sourcing the source of truth is the sequence of events. Current state can be rebuilt by reading the stream and applying domain logic or a projection.
Chronacta stores and delivers events. Aggregate business rules live in your application — Chronacta knows stream_id, event_type, and data, not what an “Order” means.
- Immutability: committed events are not edited — corrections are new events
- Append-only writes with temporal queries and replay
- Write/read decoupling: writes go to the log; reads use projections or stream reads
DDD concepts → Chronacta
Domain-Driven Design and Event Sourcing are different ideas that often work together. DDD is about language and boundaries; Event Sourcing is about how state is stored.
- Domain Event → stream record: event_type + JSON data
- Aggregate instance → usually one stream (for example order-42)
- Repository → Load = read stream + fold; Save = append with expected_version
- Bounded Context → stream naming prefixes, separate services, optional multi-tenant paths
Event Sourcing tools compared
| Criterion | Without a dedicated server | Chronacta | KurrentDB |
|---|---|---|---|
| What you run | Your app + usually PostgreSQL/SQL tables or an in-process library | Chronacta server (and optional connector for Postgres read models) | KurrentDB cluster or Kurrent Cloud |
| Source of truth | You design streams/tables, concurrency, and retention yourself | Append-only streams with stream version and global position | Native immutable event streams with stream versions |
| Optimistic concurrency | You implement expected-version / OCC on top of SQL or a library | Built-in expected stream version on append | Built-in expected version on append |
| Subscriptions | Polling, LISTEN/NOTIFY, outbox, or a message bus you add | Transient and durable subscriptions with server checkpoints | Catch-up and persistent subscriptions built in |
| Projections / read models | You write workers and SQL migrations | Server-side CEL/builtin/Starlark, durable workers, and Postgres projector via schema.yaml | Native projection engine; external read models via subscriptions |
| Schema / contracts | Application conventions or your own registry | JSON Schema Registry with versioning | Event typing and ecosystem conventions; platform tooling around contracts |
| Ops maturity & ecosystem | Depends entirely on your team’s practices | Younger product; free developer edition; CLI, admin UI, metrics, and optional high availability | Long-running product (formerly EventStoreDB); broad docs, clients, managed cloud |
| DDDesigner integration | Model aggregates, events, and projections; you write the store adapters | Schemas, manifests, adapters, and Postgres projections | No dedicated KurrentDB generation yet: model in DDDesigner, connect the store yourself |
| When it fits | Simple domains, already-strong SQL ops, or learning Event Sourcing in one service | Want a dedicated event store, a free developer edition, and generated integration from DDDesigner | Need a proven specialized platform, clients for several languages, or managed cloud |
Comparison based on public product documentation as of 2026. Chronacta and KurrentDB evolve independently; verify details against official docs before production decisions. This overview is by DDDesigner and is not sponsored by Kurrent.
How to choose among the three approaches
Without a dedicated server you keep operations simple and stay inside PostgreSQL or an in-process store, but you own concurrency, subscriptions, replay tooling, and retention. That is often enough for a first Event Sourcing service.
Chronacta adds a purpose-built event store with durable subscriptions, a schema registry, server-side projections, and a Postgres projector. Built-in DDDesigner support generates the integration.
KurrentDB (formerly EventStoreDB) is a mature specialized database with a large ecosystem and managed cloud. Choose it when you need that operational track record and are ready to connect clients yourself, without DDDesigner’s Chronacta integration path.
Projections in Chronacta
Chronacta supports several ways to build read models. When Chronacta is selected for code generation, DDDesigner maps your designed projections onto those mechanisms.
- Simple field mappings → server-side projection manifests (CEL and built-in expressions)
- Complex handlers → durable subscriptions and background workers in your service
- Postgres target → external Postgres read model via schema.yaml, sqlgen, and the connector (Chronacta remains the source of truth)
Built-in Chronacta support in DDDesigner
DDDesigner lets you model aggregates, commands, events, and projections in one place, then generate the artifacts needed to connect that model to Chronacta.
The built-in integration creates JSON schemas, projection manifests, event-store adapters, subscription scaffolding, and Postgres read-model artifacts where a projection needs them. Domain rules remain in your application, where they belong.
Frequently asked questions
Do I need Chronacta to use Event Sourcing with DDDesigner?
No. Event Sourcing can be implemented manually or with a specialized database. DDDesigner includes built-in Chronacta support, while the model can also be used with another event store.
How is Chronacta different from building Event Sourcing on PostgreSQL alone?
On PostgreSQL you implement the log, expected versions, subscriptions, and projection pipeline yourself (or via a library). Chronacta provides those as a dedicated server: streams, concurrency, durable subscriptions, schema registry, and projection tooling including a Postgres connector.
How does Chronacta compare to KurrentDB?
Both are purpose-built event stores with streams, optimistic concurrency, and subscriptions. KurrentDB has a longer production history and managed cloud. Chronacta is a specialized event store with a free developer edition and built-in DDDesigner support.
Can I use Chronacta only for local development?
Yes. Chronacta offers a free developer edition intended for local development and evaluation. Production topology and licensing should follow Chronacta’s own documentation.
DDDesigner
Model Event Sourcing with DDDesigner
Design aggregates, events, and projections visually. Use DDDesigner’s built-in Chronacta support to generate the integration, or connect your own event store.
Get started