KurrentDB: an event-native database for event sourcing and CQRS

What KurrentDB is, and the rename that confuses search results

KurrentDB is the product formerly called EventStoreDB, and the company formerly called Event Store now trades as Kurrent. The README states the rebrand directly: the flagship product is "the Kurrent event-native data platform", EventStoreDB becomes KurrentDB, and Event Store Cloud becomes Kurrent Cloud. That single paragraph explains most of the confusion you will meet when searching, because tutorials, Stack Overflow answers and blog posts written before the rename still use the old name for the same binary and the same gRPC protocol.

The problem it addresses is narrow and specific. Most databases store the current state of a thing and overwrite it when the thing changes. An event-native database stores the sequence of changes instead, and derives current state by reading that sequence. The README frames this as an "event-native design" that "simplifies data modeling and preserves data integrity", with an "integrated streaming engine" handling distributed messaging and consistency. The intended audience is teams building event-driven architectures, and the repository topics confirm it: cqrs, event-sourcing, event-store, eventsourcing. If your domain is a ledger, an order lifecycle, an audit trail or anything where "how did we get here" matters as much as "where are we now", the storage model matches the problem. If your domain is a product catalogue with frequent in-place edits and ad hoc queries, it does not.

The mechanism: append-only streams, gRPC clients and projections

The architecture visible from the repository is a C# server exposing gRPC, with client libraries maintained per language. The README lists supported clients for Python (kurrentdbclient on PyPI), Node.js, Java, .NET, Go and Rust, plus community-supported Elixir and Ruby clients. Legacy .NET clients exist but the README states their support ends with EventStoreDB v23.10 LTS, so a new project should start on a current client rather than the legacy package.

Data flows in one direction. A client appends events to a named stream over gRPC; the server persists them in order; other clients subscribe to that stream or to a category of streams and react. The README describes the streaming engine as solving "distributed messaging challenges" and ensuring "data consistency", which is the argument for putting the log and the message bus in the same process instead of running a broker beside a database and reconciling the two.

The repository also carries proto/ and proto.lock, with protolock.ps1 and protolock.sh scripts at the top level. That is a wire-compatibility guard: the gRPC contract is versioned deliberately, and the lock file records the shape of the protocol so changes are detected rather than discovered by a client in production. For anyone writing a client in a language without an official library, proto/ is the specification to work from. Projections appear in the repository topics and in search behaviour, but the README itself does not document the projection API; that lives in the user documentation at docs.kurrent.io.

Installing KurrentDB with Docker and appending a first event

The README points to the downloads page for the latest version and to docs.kurrent.io for installation guidance, and it gives build instructions for running from source. Building from source requires .NET SDK 10.0 and produces a Release build:

dotnet build -c Release

A single node then starts with the dev flag, which the README shows alongside explicit paths for data, index and log directories:

dotnet run --project ./src/KurrentDB/KurrentDB.csproj -c Release -e ASPNETCORE_ENVIRONMENT=Development -- --dev --db ./tmp/data --index ./tmp/index --log ./tmp/log

The repository also ships a docker-compose.yml that builds a three-node cluster from the local Dockerfile and generates certificates through the eventstore/es-gencert-cli image. It is a cluster fixture, not a quick start, and it expects a RUNTIME build argument plus a shared.env file. Each node maps container port 2113 to a host port starting at 2111, and the node environment variables follow the KURRENTDB_ prefix, for example KURRENTDB_GOSSIP_SEED and KURRENTDB_REPLICATION_IP. Note the licensing variable in that file, KURRENTDB__LICENSING__LICENSE_KEY, which is passed through from the environment.

To build a single image yourself, the README gives this form:

docker build --tag mykurrentdb . \
--build-arg CONTAINER_RUNTIME=noble \
--build-arg RUNTIME=linux-x64

On Windows the README warns that you may need to set DOCKER_BUILDKIT=0 because of a known BuildKit issue, and shows the PowerShell equivalent. Once a node is running, the next step is a client: pick the package for your language from the supported list and follow the gRPC getting-started guide, which is where the actual append and subscribe calls are documented.

Where KurrentDB is the wrong tool

The README does not document rollback, and it does not document a query language. That absence is the honest limitation. There is no SQL surface here, no joins, no ad hoc aggregation across streams. If a reporting tool needs to run an arbitrary query against your data, an event store is the wrong place to point it, and you will end up projecting events into a read store anyway.

The second limitation is operational weight. The repository's own docker-compose.yml is a three-node cluster with a certificate generation step, gossip seeds, replication IPs and per-node advertise settings. That is the shape of the system when you want availability, and it is a meaningful step up from running a single container. The README offers Kurrent Cloud as the managed alternative, which is an admission that self-hosting a cluster is real work.

Third, the client story is uneven by language. Six languages have official clients, Elixir and Ruby are community-supported, and the legacy .NET client is on a clock tied to EventStoreDB v23.10 LTS. A team writing in a language outside that list is committing to implementing the gRPC protocol against proto/ themselves. That is possible, since the lock file and proto directory are in the repository, but it is not a weekend task.

Finally, the licensing file is named LICENSE.md and the repository's licence is reported as NOASSERTION, which means the automated classifier could not map it to a standard identifier. The README's only guidance is to view the licensing information. Do not assume permissive terms from the presence of the source on GitHub.

KurrentDB compared with Kafka and with relational event sourcing

The comparison people reach for is Kafka. Both are append-only logs, but they are built for different consumers. Kafka's unit is the topic and its primary contract is throughput between producers and consumer groups; retention is a policy you set, and long-term storage of the full history is not the default assumption. KurrentDB's unit is the stream, and the stream is the durable record of a domain entity's history. Reading a single entity's events in order is the central operation, not a partition scan. If your problem is moving high-volume data between services, Kafka is the better-shaped tool. If your problem is reconstructing one aggregate by replaying its events, KurrentDB's model fits without you building the indexing yourself.

The other comparison is doing event sourcing on PostgreSQL. That works, and plenty of teams do it: an events table with a sequence column, a unique constraint on stream id plus version, and a read model built by a consumer. The difference in approach is that with PostgreSQL you own the subscription mechanism, the ordering guarantees, the catch-up logic and the projection runner. KurrentDB ships those as part of the server, which is the trade you are making: less code to write, more operational surface to run. The README does not benchmark this trade-off, and neither should anyone quoting it.

Maintenance, releases and upgrade cost

The repository is not archived and the last push was on 2026-09-22. Recent releases include v24.10.16 on 2026-09-01, v24.10.15 on 2026-08-19 and v26.1.2 on 2026-08-11. Two release lines are being maintained in parallel, which is the pattern you want if you run the LTS line and want patch releases without moving to a new major.

The upgrade cost is visible in the contributing section. Development happens on master, pull requests are squashed into a single commit on merge, and the README tells you to check out a release branch to switch to a particular release, with `git checkout release/v25.0` as the example. That means the branch name encodes the version line, and the version lines above do not obviously match the example branch, so confirm which branch corresponds to the release you intend to run before you build from source.

Building from source also pins you to .NET SDK 10.0, per the prerequisites and the Dockerfile's use of mcr.microsoft.com/dotnet/sdk:10.0-noble. The Dockerfile carries a comment that the build cannot run on Alpine and uses noble as the base image, so a musl-based build is not an option the repository supports. The proto.lock file is the other upgrade signal: if the protocol lock changes between the version you run and the version you upgrade to, your client needs attention, and the lock file is how you find out before deployment rather than after.

On licensing, the repository separates LICENSE.md from LICENSE_CONTRIBUTIONS.md, which suggests the terms for using the software and the terms for contributing to it are not the same document. Read both, and read the licensing page the README links to, before you decide whether the deployment you have in mind is covered. Nothing here is legal advice; the point is that the README does not tell you, and the classifier could not either.

Editorial conclusion

Adopt KurrentDB when your domain is already event-shaped and you want the stream, the subscription and the projection in one process rather than three. Do not adopt it as a drop-in replacement for a relational database holding current state, and do not adopt it if you cannot read the licensing terms in LICENSE.md before you deploy. Verify first that the client library for your language is one of the supported gRPC clients rather than a legacy one, check which release branch matches the version you intend to run, and confirm whether you need a license key at all by reading the licensing page rather than the README.

Frequently asked questions

Official sources

1. Issues
2. kurrent-io/KurrentDB on GitHub
3. Project website
4. README
5. Releases