Immutable write-side database system

EventDBX exists to make data trustworthy — by treating every change as an event, cryptographically verified and reproducible.

Use the EventDBX CLI directly from npm when you want a zero-container setup.

$ npm install eventdbx -g
$ dbx start --foreground
$ dbx token bootstrap --stdout

Use the EventDBX Client SDK in your preferred language to develop your application.

DocumentationGitHubClient SDKs

© 2025Patrick ThachPrivacy PolicyTerms of Service

Remote Database

I focused on making data accessible between peers. Users can now run dbx checkout -c <domain> --remote <host>:<port> --token <remote_token> to attach remote databases.

Users can then push/pull data and schema between peers: dbx push <domain> or dbx pull <domain> and dbx push schema <domain> or dbx pull schema <domain>

Improvements

  • Multitenancy: Tenants are segregated by sharding, and tokens can be assigned to specific domains, preventing permission leakage.
  • Observability: Added a Prometheus-compatible /metrics endpoint to report traffic and plugin queue health, making EventDBX compatible with Grafana, Datadog, and other monitoring stacks out of the box.
  • Schema versioning: Schemas now support versioning, activation, publishing, rollback, and diff comparisons between versions.
  • Replication: Data and schema are segregated by sharding instead of by directory, introduced watch to automate replication cycles.

Stabilization / Performance Testing

This phase focused on fine-tuning various areas of the system, now called EventDBX — the “X” stands for extra, representing the plugin architecture that allows developers to extend functionality by subscribing to events published through the EventDBX queue system.

The core API interfaces such as REST, GraphQL, and gRPC were decoupled into individual plugins, allowing users to install only what they need. This approach keeps EventDBX lean and focused solely on being the write-side database.

Improvements

  • Cross-platform CLI: EventDBX is now accessible on Windows, macOS, and Linux with a single command: npx dbx start
  • Containerized deployment: A Docker image is now available, making it easy to deploy to GCP, AWS, or Azure in production environments.
  • Performance: Benchmark tests confirm EventDBX is extremely fast compared to traditional database systems.
  • Plugin architecture: The core focuses exclusively on the write-side, while plugins handle read-side operations. The internal queue system includes retry and dead-letter mechanisms to ensure reliable event publishing to custom plugins.
  • Client SDKs: Official client libraries are now available for Go, Python, TypeScript/JavaScript, Java, Rust, and .NET.

Memory-Safe Database

There has been a growing government push for future software systems to be memory-safe, encouraging developers to adopt memory-safe programming languages. It is determined that Rust is the best language for developing what is now called EventDB. Rust offers high performance, memory safety, and concurrency safety—three critical traits for a database system. However, learning Rust is challenging; its ownership and borrowing concepts can be difficult to grasp at first.

Building a write database entirely from scratch isn’t practical. Instead, RocksDB, with its Log-Structured Merge (LSM) design, makes perfect sense and aligns naturally with the vision of EventDB as a write-focused database.

Improvements

  • Replication (non-distributed): EventDB allows sharing schemas and databases between peers without requiring full distributed consensus.
  • Secure at rest / in transit: Communication is protected using the Noise Protocol framework.
  • Passwordless authentication: EventDB uses JWT token-based authentication, eliminating the need to manage user credentials directly.
  • Immutable data: Once written, data cannot be altered or permanently deleted from the system, ensuring a verifiable and tamper-proof history.
  • Schema validation: Supports built-in formats (email, URL, WGS84, and more) with rule blocks for length, range, regex, required fields, and nested properties, along with strict or relaxed enforcement modes.

What is a Write-Side Database?

Based on the CQRS (Command Query Responsibility Segregation) design pattern, there should be a clear distinction between the write database and the read database.

The write-side database doesn’t need to scale horizontally, but it should be more than just writing data to disk. It must be flexible, extensible, and secure, with the ability to track every change over time. It should be customer-facing in purpose—built for developers who are creating applications that serve users, not for database administrators who think in CRUD operations.

A write-side database should encourage task-based thinking rather than CRUD-based thinking. Developers should model actions and outcomes—what the customer is actually trying to accomplish—rather than tables and fields. This shift in mindset helps developers move faster and focus on delivering real value instead of managing data structures.

CRUD-Based Thinking (Conventional Databases)

  • Focused on data manipulation — Create, Read, Update, Delete.
  • State is mutable and impermanent.
  • History is often an afterthought (logging, auditing, etc.).
  • Leads to fragile systems that do not explain their past.

Task-Based Thinking (Our Philosophy)

  • Focused on intent and causality — every change is a task or event.
  • State is derived, not stored.
  • History is immutable and verifiable (Merkle-tree + Noise-secured).
  • Systems become transparent, testable, and replayable.

A write-side database should also serve as the source of truth for all systems. This means that while state can change, every change in state must be event-driven and carry a clear, purposeful context.

The project is originally called EventfulDB. It began as a TypeScript prototype, designed to bridge the gap between analytical systems like BigQuery and event-driven applications. However, while Node.js and TypeScript made it easy to experiment, they are ultimately too slow and too high-level for a true database system—one that demands the performance, safety, and precision of a systems language.