KurrentDB — Event Store Database for Event Sourcing and CQRS

Introduction

KurrentDB (formerly EventStoreDB) is an open-source database purpose-built for event sourcing. Instead of storing the current state of entities, it stores an immutable, append-only log of every state change as a sequence of events. Applications reconstruct current state by replaying events, gaining a complete audit trail and the ability to project data into multiple read models. KurrentDB provides built-in subscriptions and server-side projections that react to events in real time.

What KurrentDB Does

• Stores events as immutable, append-only streams with guaranteed ordering
• Provides catch-up and persistent subscriptions for real-time event consumption
• Runs server-side projections in JavaScript to create derived streams and read models
• Supports optimistic concurrency control for safe concurrent writes to streams
• Clusters with leader-follower replication for high availability

Architecture Overview

KurrentDB persists events in a transaction log on disk, indexed by stream ID and global position. Each stream is an ordered sequence of events identified by a category and an entity ID. The server runs a projection engine that processes events through user-defined JavaScript functions to produce new derived streams. Clients connect via gRPC or HTTP, and subscriptions push new events to consumers with checkpointing for reliable delivery.

Self-Hosting & Configuration

• Deploy via Docker, Linux packages, or Kubernetes Helm chart
• Configure cluster topology with --cluster-size for multi-node setups
• Set --run-projections=All to enable the built-in projection engine
• Use TLS certificates for production security with --certificate-file and --certificate-private-key-file
• Tune --mem-db for in-memory mode during development and testing

Key Features

• Immutable event log provides a complete audit trail by design
• Server-side projections transform and aggregate events without external tooling
• Persistent subscriptions distribute work across competing consumers
• Optimistic concurrency with expected version checks prevents write conflicts
• Built-in stream metadata controls access, max age, and max count per stream

Comparison with Similar Tools

• Apache Kafka — distributed log for high-throughput messaging; KurrentDB is optimized for per-entity event streams and projections
• PostgreSQL with event tables — requires manual indexing and subscription logic; KurrentDB provides these natively
• Axon Server — Java-centric event store; KurrentDB is language-agnostic with gRPC and HTTP APIs
• Marten — .NET library using PostgreSQL; KurrentDB is a standalone database with built-in clustering

FAQ

Q: What is the difference between EventStoreDB and KurrentDB? A: KurrentDB is the renamed and continued development of EventStoreDB under the Kurrent brand. The core functionality and APIs remain the same.

Q: Can I query events across multiple streams? A: Yes. KurrentDB provides a global $all stream and category projections (e.g., $ce-order) that aggregate events from related streams.

Q: How does KurrentDB handle schema evolution? A: Events are stored as JSON or binary payloads. Schema evolution is handled at the application level through upcasting or versioned event types.

Q: Is KurrentDB suitable for high-throughput workloads? A: Yes. KurrentDB handles tens of thousands of writes per second on commodity hardware and scales reads through follower nodes and caching.

Sources

• https://github.com/kurrent-io/KurrentDB
• https://developers.eventstore.com/