Table of Contents
Fetching ...

ActorDB: A Unified Database Model Integrating Single-Writer Actors, Incremental View Maintenance, and Zero-Trust Messaging

Jun Kawasaki

TL;DR

ActorDB tackles the architectural complexity of modern data-intensive applications by unifying a single-writer, actor-based write model, Incremental View Maintenance, and a zero-trust security framework into a single database system. The approach tightly integrates actor persistence with on-demand projections, including dynamic materialized-view promotion driven by query patterns and SLOs, all under a security layer with mTLS, JWS, ABAC/RBAC with RLS, and auditing. Key contributions include the Write Model, Read Model, Security Layer, a consistent intra-actor model with eventual cross-actor consistency via sagas, and a process-network (dag.jsonnet) for coherent deployment and operation, along with MVP criteria and an initial in-memory prototype demonstrating strong write throughput and low read/end-to-end latency. The work aims to reduce architectural complexity, improve security by default, and enhance developer experience, while outlining concrete future work to build a full prototype and benchmark it against traditional multi-component stacks.

Abstract

This paper presents ActorDB ( Dekigoto ) , a novel database architecture that tightly integrates a single-writer actor model for writes, Incremental View Maintenance (IVM), and a zero-trust security model as a core component. The primary contribution of this work is the unification of these powerful but complex concepts into a single, cohesive system designed to reduce architectural complexity for developers of modern, data-intensive applications. We argue that by providing these capabilities out-of-the-box, ActorDB can offer a more robust, secure, and developer-friendly platform compared to solutions that require manual integration of separate systems for actor persistence, stream processing, and security. We present the core architecture, discuss the critical trade-offs in its design, and define the performance criteria for a Minimum Viable Product (MVP) to validate our approach.

ActorDB: A Unified Database Model Integrating Single-Writer Actors, Incremental View Maintenance, and Zero-Trust Messaging

TL;DR

ActorDB tackles the architectural complexity of modern data-intensive applications by unifying a single-writer, actor-based write model, Incremental View Maintenance, and a zero-trust security framework into a single database system. The approach tightly integrates actor persistence with on-demand projections, including dynamic materialized-view promotion driven by query patterns and SLOs, all under a security layer with mTLS, JWS, ABAC/RBAC with RLS, and auditing. Key contributions include the Write Model, Read Model, Security Layer, a consistent intra-actor model with eventual cross-actor consistency via sagas, and a process-network (dag.jsonnet) for coherent deployment and operation, along with MVP criteria and an initial in-memory prototype demonstrating strong write throughput and low read/end-to-end latency. The work aims to reduce architectural complexity, improve security by default, and enhance developer experience, while outlining concrete future work to build a full prototype and benchmark it against traditional multi-component stacks.

Abstract

This paper presents ActorDB ( Dekigoto ) , a novel database architecture that tightly integrates a single-writer actor model for writes, Incremental View Maintenance (IVM), and a zero-trust security model as a core component. The primary contribution of this work is the unification of these powerful but complex concepts into a single, cohesive system designed to reduce architectural complexity for developers of modern, data-intensive applications. We argue that by providing these capabilities out-of-the-box, ActorDB can offer a more robust, secure, and developer-friendly platform compared to solutions that require manual integration of separate systems for actor persistence, stream processing, and security. We present the core architecture, discuss the critical trade-offs in its design, and define the performance criteria for a Minimum Viable Product (MVP) to validate our approach.

Paper Structure

This paper contains 23 sections, 1 table.