Show HN: Mori – Test against production data, without ever touching production

1 point

3 months ago

Mori is an open-source database proxy that lets you run your application locally against real production data without risking writes to production. It connects to your production database, clones the schema locally, and intercepts queries: - Reads come from production - Writes / migrations / deletes are executed only in a local shadow database - Results are merged in real time so your app thinks the changes happened in production

So you (and your AI agents) can safely test your code in a verifiable environment (real production data) locally before you're ready to push.

Links: - Demo -> https://moridb.sh/demo - Repository -> https://github.com/psrth/mori - Docs -> https://moridb.sh/docs

Motivation: Most people ask Santa for a bicycle; every year, I've been asking for the ability to test in prod. The existing alternatives (branching, snapshots, seed dbs, staging dbs, good old pg_dump) are one or more of: (a) out of sync, (b) expensive to run (time and cost), (c) cloud / managed provider only. But as AI agents continue to write more code, our local testing frameworks need to keep up. Writing code shouldn't be artificially bottlenecked or a literal leap of faith.

Implementation: The docs have a lot more information, but a summary: - Support for PSQL/MySQL/SQLite + 6 more engines, each with custom AST-level query classification and rewriting - In-flight cross-DB merging of prod data with local modifications - Collision-free PK generation and support for foreign keys - Full transaction support including CTEs, nested transactions, and savepoints - MCP support: plug-and-play into Claude Code, Cursor, or wherever you get your tokens - Exhaustive E2E test suite per engine

Safety: I want to specifically call out the core design principle — that production should never be writable through Mori. This is enforced through four independent layers:

1. Query classification — every statement is parsed and classified as read or write before routing 2. Routing rules — writes are deterministically routed to the local shadow database, never forwarded 3. Shadow execution enforcement — even if classification is bypassed, the execution layer rejects any write targeting the production connection 4. Raw byte inspection — finally, outbound bytes on the production socket are inspected to ensure no write operation ever reaches prod

If any layer fails to classify a query, Mori refuses the statement entirely rather than risking a pass-through.

Note: While I've validated (and extensively tested against our production database) all of the supported queries, there may (and will) be edge cases that I haven't discovered yet. If you hit an edge case, please open an issue - expanding the current coverage is my top priority!

If you want to see if this repo is a good fit for your workflow, you can checkout > https://www.moridb.sh/docs/resources/compatibility.

Or, in the true spirit of this project, just go for it :) > curl -fsSL https://moridb.sh/install.sh | sh