Long Execution Paths
Business operations are split into repeated cross-process and cross-network calls between service frameworks, protocols, and databases.
AI Writes, Machines Verify, Database-Native Execution
MuduDB
Bring Applications Into the Database Runtime
Let AI Agents Access Databases Safely
A unified execution and data management platform for data-intensive applications, integrating transaction processing, application logic, state access, and deployment into a single database runtime.
Business actions generated by AI agents first enter the CQL formal semantic layer, where they are symbolized into checkable specifications and machine-judged by the compiler and model checker before execution, then guarded by the WASM controlled runtime and the database kernel — only what passes is executed, making every data access verifiable, rejectable, and replayable.
MuduDB
Bring Applications Into the Database Runtime
Let AI Agents Access Databases Safely
§
Prompt
{ }
CQL Spec
Σ
Model Checking
λ
Compiled Operator
[#]
Database
Problem
Data-intensive applications are slowed down by system boundaries
In traditional architectures, application logic runs outside the database. A single operation often crosses application services, network protocols, drivers, connection pools, SQL executors, and transaction managers.
Split Transaction and Business Logic
Transaction semantics remain inside the database while business procedures live in application services, forcing developers to manually maintain consistency.
Complex Deployment and Operations
Applications, databases, dependencies, scripts, and configurations are deployed separately, and integration cost grows with system scale.
AI Agent Pain Points
AI agents stall at the last mile: writes with no pre-execution verification
Enterprises dare not let agents touch production databases — not because models are too weak, but because there is no verifiable, rejectable, replayable write path.
No Safety Guarantee for Agent Writes
"Don't misbehave" in prompts, manual approval per operation, and read-only replicas are all might-work stopgaps — either unsafe, or useless.
The Real Value Is in Writes
Refunds, price changes, inventory deductions, order edits — the last mile of agent capability is writing, yet no mechanism can judge whether LLM-generated SQL or code is safe before execution.
One Mistake Is an Incident
AI takes no responsibility for safety or quality; a single wrong write is a real loss. Letting agents touch production databases has become the top reason enterprise AI adoption stalls.
Solution
MuduDB brings application procedures into the database runtime
Developers can write data-intensive business procedures in familiar programming languages, then compile, package, and deploy them directly inside the database. The database becomes a unified platform for data management, transaction processing, application execution, and deployment distribution.
Get Started
Deploy applications inside the database in minutes
Package your schema, procedures, and assets, then deploy them directly into the MuduDB runtime. No separate application servers needed.
1
$ mpm-install your-application.mpk
CQL Verification
AI writes — machines verify — the database executes natively
CQL (Churcuring Query Language) is the semantic layer of MuduDB, redesigned for machine generation plus machine verification: business actions produced by AI agents are first symbolized into checkable specifications, then machine-judged by the compiler and the model checker before execution — only what passes is allowed to run.
AI → SQL → manual review / direct execution: constraint violations surface only in after-the-fact reconciliation
↓
AI → CQL → verification → execution: machine-judged before execution, released only when proven safe
Prompt → CQL Spec → Model Checking → Compiled Operator → Database
Churcuring Query Language
§
Prompt
Natural-language intent; LLMs generate it well, no new language for humans to learn
{ }
CQL Spec
Strongly-typed specifications of tables, actions, queries, invariants, and temporal properties
Σ
Model Checking
Invariants verified over all reachable states; counterexamples are replayable
λ
Compiled Operator
Sandboxed WASM execution units running close to the data
[#]
Database
Violating code is screened out at the leftmost end of the pipeline; the kernel only receives verified, trusted execution
Compilation Is Review
Type errors, effect violations, and unexpected divergence are all intercepted at compile time and never reach the execution environment.
Three-Tier Effect Isolation
Pure functions, read-only queries, and write transactions are tiered and may only compose upward; no JOINs — every association is an explicit key lookup.
Total Determinism
Same snapshot plus same parameters yields identical results — the engineering prerequisite for formal verification.
What Is Checked Is What Runs
The checker and the kernel share the same constraint rules and evaluation semantics, so a verified module runs exactly as verified.
Architecture
Semantic Layer · Runtime · Kernel: A Three-Tier Unified Architecture
MuduDB adopts a three-tier architecture of semantic layer, runtime, and kernel. At the top, the CQL formal semantic layer takes business actions generated by AI agents and subjects them to type checking, effect checking, and model checking; verified logic is compiled into WASM application packages hosted by the runtime, which accesses kernel capabilities through lightweight syscalls; the kernel provides storage, transaction, query, and scheduling capabilities.
CQL Formal Semantic Layer
Type CheckingEffect TiersModel CheckingInvariants & Temporal Properties
Mudu Package
WASM BytecodeSchemaProceduresAssets
MuduDB Runtime
WASM HostProcedure EngineSyscall Layer
MuduDB Kernel
TransactionQueryKVStorageScheduler
Local / Cloud / Edge Nodes
DeploymentDistributionExecution Locality
Video Overview
Capabilities
Core capabilities for database-native applications
CQL Formal Semantic Layer
Describe business as tables, actions, queries, invariants, and temporal properties, turning AI agent output into strongly-typed, effect-tiered, checkable specifications.
Pre-Execution Model Checking
Compilation is review: the model checker verifies invariants over all reachable states, violating code is intercepted before deployment, and counterexamples replay into regression tests.
In-Database Application Execution
Deploy data-intensive procedures into the database runtime to reduce cross-process, cross-network, and cross-service overhead.
Portable WASM Runtime
Use a WebAssembly-based runtime model for cross-platform and cross-language procedure execution.
Unified Syscall Interface
Access database kernel capabilities through lightweight, stable syscalls instead of heavy driver and connection objects.
Transaction-Procedure Coordination
Coordinate transaction processing, state access, and business logic within the same execution path.
Data-Local Execution
Use partitioning and data locality to move computation close to data for low-latency and high-concurrency services.
Application Package Distribution
Package schema, procedures, dependencies, and initialization scripts so database applications can be installed and upgraded like software.
Scenarios
Where MuduDB fits
Enterprise Transaction Processing
Orders, inventory, accounts, approvals, and settlement procedures execute close to transactional state.
Cloud Platform Services
Build multi-tenant, high-concurrency, low-latency data services that unify data access and business procedures.
Intelligent Data Applications
Provide a unified execution, state, and deployment substrate for AI-generated and data-heavy applications.
Massively Multiplayer Online Games
Serve high-frequency state updates, transactional operations, and locality-intensive backend workloads.
Research
Research and White Papers
MuduDB explores a new boundary between database systems, application runtimes, and data service architectures.
System Architecture Soon Technical White Paper Soon Paper Draft Soon Benchmark & Evaluation Soon
Open Source
Open Source First
MuduDB is evolving as an open-source system. We welcome stars, trials, feedback, and contributions.
Roadmap
From kernel prototype to application marketplace
Phase 1
Kernel Prototype
Phase 2
WASM Procedure Runtime
Phase 3
Package & Deployment
Phase 4
Distributed / Local-first Execution
Phase 5
Marketplace