DBMS > KurrentDB (aka EventStoreDB)
KurrentDB (aka EventStoreDB) System Properties
Please select another system to compare it with KurrentDB (aka EventStoreDB).
Editorial information provided by DB-Engines | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Name | KurrentDB (aka EventStoreDB) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | An event-driven database that records every change as an immutable event, indexes it for fast access via fine-grained streams, and projects it into state exposed via pub/sub or database tables for efficient event-driven workflows. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Primary database model | Event Store | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Secondary database models | Document store ![]() Time Series DBMS ![]() | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Website | www.kurrent.io | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Technical documentation | docs.kurrent.io | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Developer | Kurrent, Inc. (formally, EventStore Limited) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Initial release | 2012 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Current release | 25.1, October 2025 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
License ![]() | Source Available | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Cloud-based only ![]() | no ![]() | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DBaaS offerings (sponsored links) ![]() Providers of DBaaS offerings, please contact us to be listed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Implementation language | .NET/C# | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Server operating systems | Docker Kubernetes Linux Windows | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data scheme | schema-free | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Typing ![]() | Yes: JSON event data and metadata; Binary event data; Strongly-typed language interfaces | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
XML support ![]() | Partial: Store XML as string data; Convert XML to JSON; Base64 encode XML ![]() | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Secondary indexes | Two virtual index streams built on the most frequently queried metadata fields. Consumers use them by pointing their stream filter to the index stream via the Read/Subscription API. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SQL ![]() | Introspective SQL for simplified metrics collection of system, database, and application operations | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
APIs and other access methods | Archiving ![]() Client SDKs ![]() gRPC API ![]() HTTP API ![]() Management API ![]() MCP Server ![]() Navigator ![]() OpenTelemetry Exporter ![]() Prometheus Metrics ![]() Pub / Sub API ![]() Web UI ![]() | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Supported programming languages | .NET/C# Go Java Node.js Python Rust | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Server-side scripts ![]() | User-Defined Projections, System Projections, Projection Configuration Options, Server Administration Scripts, Connector Transformations | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Triggers | Projections, Persistent Subscriptions, Catch-up Subscriptions, Connectors | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Partitioning methods ![]() | Stream Level Partitioning, where each stream holds the events for a single entity or process (e.g., customer-123, order-456); Stream boundaries that align with business aggregates / entities and transactional consistency requirements; Fine-grained vs. coarse-grained streams - KurrentDB promotes fine-grained streams without expensive re-partitioning; Category-based organization where streams can be grouped by categories for easier management; Support for billions of streams, so reads/writes touch only the relevant stream, improving latency, scalability, and maintenance; For downstream pipelines (e.g., Kafka), partitions can be aligned by stream ID, suffix, or event headers, keeping physical partitioning consistent with KurrentDB’s logical model | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Replication methods ![]() | Built-in Clustering Replication ![]() Event Distribution Methods ![]() External System Replication ![]() Kurrent Replicator ![]() | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MapReduce ![]() | Event-native processing and streaming; Data Pipeline Integration; Distributed Processing Patterns; KurrentDB offers event-native processing and streaming: User-Defined Projections - JavaScript-based server-side processing for transformations and state aggregations across streams; System Projections - Built-in indexing by category, event type, and correlation ID for efficient event retrieval; Data Pipeline Integration: Native Connectors - Real-time event streaming to external systems where MapReduce processing could occur (e.g. Spark/Hadoop via Kafka or files via HTTP); Event Export - Stream events to data processing platforms that do support MapReduce; Distributed Processing Patterns: Stream Processing - Events can be processed in parallel across multiple subscribers; Event Replication - Distribute events across multiple systems for parallel processing | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Consistency concepts ![]() | Append-only Log - Events are only appended and never modified, serving as an immutable audit trail of all historical changes Atomic writes of events - entire batch of events submitted in the same write. Eventual Consistency - KurrentDB supports eventually consistent systems where all parts of a distributed system will eventually return the same values, typically within milliseconds to seconds rather than large spans of time Guaranteed Consistent Ordering - Events are consistently ordered in the order they were appended across both the event log and streams, ensuring events are always read in the same consistent order Guaranteed Write Durability - Writes are guaranteed to be fully durable once acknowledged Immutable Events - All events cannot be altered once appended, ensuring data integrity and consistent audit trails Optimistic Concurrency Control - Prevents lost updates from concurrent appends using a lock-free approach to reduce contention and performance overhead Quorum-based Replication - High availability clusters use secure, quorum-based replication with leader election via gossip protocol Read-only Replicas - Asynchronous replication for scaling read operations without participating in write operations or quorum decisions Sequential Event Numbering - Events are automatically assigned strictly monotonically increasing numbers (without gaps) within their stream to ensure reliable state reconstruction and concurrency handling Stream-level Consistency - KurrentDB can ensure data consistency within a stream when multiple writers are trying to append concurrently Transactional vs Eventual Consistency - The system allows you to consciously choose consistency boundaries so business requirements are met, with everything else being eventually consistent | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Foreign keys ![]() | None, but Kurrent DB provides other event-native consistency guarantees: Correlation IDs - Events can include correlation IDs to link related events across different streams; Event-driven associations - Use projections to build read models that represent relationships between entities; Application-level validation - Business logic in your application ensures data integrity rather than database constraints; Event sourcing patterns - Model relationships through the sequence and content of events rather than foreign key constraints; Optimistic concurrency control - Prevents lost updates during concurrent writes; Sequential event numbering - Ensures reliable state reconstruction; Immutable events - Once written, events cannot be altered, providing audit trail integrity | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Transaction concepts ![]() | Writes use an implicit transaction: all records are appended contiguously in the same chunk and committed atomically. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Concurrency ![]() | Traditional databases rely on pessimistic locking, KurrentDB's event-driven architecture with optimistic concurrency control provides better scalability while maintaining data consistency through its append-only, immutable event model; Optimistic Concurrency Control: Lock-free approach - Concurrent appends that lead to lost updates can be prevented with optimistic concurrency control, done in a lock-free way to reduce contention and performance overhead; Stream-level consistency - KurrentDB can ensure data consistency within a stream when multiple writers are trying to append concurrently; Sequential event numbering - Events are automatically assigned strictly monotonically increasing numbers (without gaps) to ensure reliable state reconstruction and concurrency handling; Stream Position Management: Unique event positions - Each event has its own unique position within a stream, represented by a numeric, incremental value that can be used to define order and detect concurrency issues; Race condition prevention - The position system helps prevent accidental overwrites or lost updates due to concurrency and race conditions; Distributed Concurrency: Quorum-based clustering - High availability clusters use secure, quorum-based replication with leader election via gossip protocol for distributed concurrency management; Multiple competing consumers - Persistent subscriptions support multiple competing consumers with checkpointing and retries | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Durability ![]() | Core Durability Features: Guaranteed Write Durability - Writes are guaranteed to be fully durable once acknowledged, ensuring data is safely persisted to disk; Immutable Events - All events stored in KurrentDB cannot be altered once appended, ensuring data integrity and durability over time; Append-only Log - Events are only appended and never modified, serving as an immutable audit trail that captures all historical changes; Storage and Backup Durability: Backup and Restore - Comprehensive backup functionality for full or differential backups and restores over disk snapshots or file copy backups; Event Store Replicator - Tool for facilitating replication or migration of data between different KurrentDB clusters to ensure data durability across environments; Archiving / DR - Archive to ObjectStore or long-term data retention; Clustering for High Durability: High Availability Clustering - Uses secure, quorum-based replication with leader election via gossip protocol, where each node independently maintains data without shared disks; Read-only Replicas - Asynchronous replication to additional nodes for enhanced data durability and read scaling | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
User concepts ![]() | KMS Integration (for connectors) Kubernetes Operator Role-based access controls LDAP integration Mutual TLS / X.509 authentication OAuth authentication Password-based authentication Role-Based Access Control Stream Access Policy Stream ACLs | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
More information provided by the system vendorWe invite representatives of system vendors to contact us for updating and extending the system information, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Related products and servicesWe invite representatives of vendors of related products to contact us for presenting information about their offerings here. |
Share this page