Skip to main content
Mori is a transparent proxy that sits between your application and a production database. Your application connects to Mori using a standard database driver — same wire protocol, no code changes beyond swapping a connection string. Writes are captured in a local database instance (the Shadow) that starts as a clone of production (schema-only for SQL engines, full file copy for embedded engines, seeded with data for Firestore). Reads are served from the real production database, merging with any changes made in the shadow in-flight. The result? Developers and AI agents can test against real production data, mutate freely, and never risk modifying the production database. Break something, reset, start over.

​
Why Mori

  • Real data, zero risk — Query live production data. All writes are isolated in a local shadow database.
  • No code changes — Same wire protocol, same driver. Swap one connection string.
  • Multi-engine support: — PostgreSQL, CockroachDB, MySQL, MariaDB, MSSQL, SQLite, DuckDB, Redis, Firestore (more coming soon!)
  • Multi-auth provider support: — AWS RDS, GCP Cloud SQL, Neon, Supabase, Azure, PlanetScale, and more.
  • MCP server — Built-in Model Context Protocol server for AI agent integration.
  • Instant reset — Wipe shadow state and get a clean view of production in seconds.

​
Quick Evaluation

Go to the compatibility assessment page to get a quick prompt for your AI agent to evaluate whether Mori is a good fit for your development workflow.

Quick Start

Get Mori running in under 5 minutes.

Core Concepts

Architecture, components, and routing strategies.

Safety

How Mori guarantees production is never written to.

Motivation

Why database virtualization exists.

Name

The meaning behind “mori”.

Roadmap

What’s coming next.

​
Core Invariants

These hold at all times, without exception.
Production is read-only. Mori never issues a write to the upstream database. A multi-layer write guard enforces this invariant even if bugs exist in any single layer.
Shadow is the mutation layer. All writes go to the Shadow database — a local instance (same engine as prod) holding all local mutations. SQL engines start schema-only with zero rows; embedded engines (SQLite/DuckDB) start as a full file copy; Firestore starts seeded with production data.
The application sees one unified database. When the app issues a SELECT, Mori transparently merges results from prod and shadow. Locally-modified rows come from shadow. Untouched rows come from prod. Complex queries merge prod rows with shadow changes in memory. The app never knows the difference.
Reset is instant. Wiping the shadow and its metadata restores a clean view of production. No migration, no rollback — just a clean slate.