Skip to main content

When not to use Celeriant

Celeriant is narrow on purpose, and adopting the wrong database is expensive. If any of these is you, use something else and do not feel bad about it.

You only need streaming​

Two services, say orders and SMS. Events flow one way and nothing downstream feeds back into a write decision. If nothing depends on shared state and you never need a conditional write, you need a log or a queue, not an event store.

You need SQL or OLAP​

Celeriant is the write side. Reads are per aggregate, by version range and event type. There is no SQL, no ad-hoc query, no secondary index across aggregates. Project into an RDBMS, DuckDB or a data lake and query there.

You need transactional reads across aggregates​

A read model is a separate store fed by projecting events, so a read is not in the same transaction as the write. That does not force staleness. Just-in-time catch-up works: the read request first replays the target aggregate's new events into its projection, then serves. Per aggregate that is read-your-writes; the cost is a catch-up read on the request path.

What you do not get is one transactional snapshot across many aggregates, the way a SELECT ... JOIN inside a transaction gives you on an RDBMS. If your reads need that, an RDBMS is the simpler tool. See Building a read model for the catch-up pattern.

You need atomic writes across arbitrary aggregates​

One write can cover several aggregates only when they route to the same shard. A write spanning shards is rejected with 9001 (ShardRoutingMultipleShards), and the shard count and routing rule are fixed when the cluster is initialised. If your invariants cut across aggregates you cannot co-locate, you are back to sagas. See Consistency boundaries.

You need more than two nodes​

A cluster is exactly one leader and one follower, with an S3-compatible bucket for the lease and fallback replication. No third replica, no multi-region quorum. See Leader election and S3 leases.

You cannot run Linux​

The server needs io_uring (kernel 5.11+) and a filesystem that supports Direct I/O. On macOS or Windows it runs only inside the container.

You need stability today​

Celeriant is pre-1.0, and minor versions still break things: 0.2.0 made breaking changes to the Rust client API. If you cannot ride that, run KurrentDB or Marten now and revisit Celeriant later.