> ## 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.

# Motivation

> Why database virtualization exists and the design trade-offs behind Mori.

## The Problem

Developing against real data is hard. The common approaches all have significant drawbacks:

* **Seed data** — Stale, incomplete, doesn't reflect production edge cases. Maintaining seeds is a constant tax.
* **Staging databases** — Expensive, drift from production, shared across the team (your changes break someone else's test).
* **Database snapshots** — Large, slow to restore, consume storage. Not practical for quick iteration.
* **Mocking** — Doesn't catch real query bugs, schema mismatches, or performance issues.

For AI agents, the problem is worse. Agents need to explore database schemas, run diagnostic queries, and test mutations — all against real data. Giving an agent write access to production is dangerous. Giving it a stale seed database produces poor results.

More importantly, the pace of development post AI is accelerating rapidly. We used to modify core tables maybe once a month after three levels of review. Now we're modifying them multiple times a day. We urgently need better environments for testing.

## The Solution

Mori gives every developer and AI agent a **virtual copy** of the production database. Reads return real production data. Writes are captured locally. Reset is instant. No data copying. No snapshot management. No staging infrastructure. Just swap a connection string.