> ## Documentation Index
> Fetch the complete documentation index at: https://moridb.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> Database virtualization with copy-on-write semantics.

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](/docs/resources/compatibility) page to get a quick prompt for your AI agent to evaluate whether Mori is a good fit for your development workflow.

## Quick Links

<CardGroup cols={3}>
  <Card title="Quick Start" icon="rocket" href="/docs/quickstart">
    Get Mori running in under 5 minutes.
  </Card>

  <Card title="Core Concepts" icon="diagram-project" href="/docs/concepts/architecture">
    Architecture, components, and routing strategies.
  </Card>

  <Card title="Safety" icon="shield" href="/docs/concepts/safety">
    How Mori guarantees production is never written to.
  </Card>

  <Card title="Motivation" icon="lightbulb" href="/docs/resources/motivation">
    Why database virtualization exists.
  </Card>

  <Card title="Name" icon="tag" href="/docs/resources/name">
    The meaning behind "mori".
  </Card>

  <Card title="Roadmap" icon="map" href="/docs/resources/roadmap">
    What's coming next.
  </Card>
</CardGroup>

## Core Invariants

These hold at all times, without exception.

<Note>
  **Production is read-only.** Mori never issues a write to the upstream database. A [multi-layer write guard](/docs/concepts/safety) enforces this invariant even if bugs exist in any single layer.
</Note>

<Note>
  **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.
</Note>

<Note>
  **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.
</Note>

<Note>
  **Reset is instant.** Wiping the shadow and its metadata restores a clean view of production. No migration, no rollback -- just a clean slate.
</Note>