Exodus Validation Runs
Validation runs are production-shaped exercises for Exodus. They prove that migration behavior, live traffic handling, validation, and observability work together before a production cutover. Production validation should use external live traffic rather than a write loop embedded inside the migration script.
Validation Modes
| Mode | Source write path | Target live write path | Historical copy contention | Safety gate |
|---|---|---|---|---|
| Strict dual-write | Write source. | Translate and write target before success. | Target receives historical copy and live writes together. | Live target write failures block the request. |
| LogAndReplay | Write source. | Translate and append to durable log storage. | Historical copy can run without target live-write pressure. | Replay readiness must pass before switching to strict dual-write. |
Strict dual-write is the simplest correctness story: after migration starts, each compatible write must succeed on both systems before Eve returns success to the client.
LogAndReplay is optimized for faster historical movement. Eve writes to the source, translates the write to the target protocol, appends it to durable log storage, moves historical data as fast as possible, replays the log into the target, then switches to strict dual-write after replay catches up.
Postgres And MongoDB Mapping Example
Postgres -> MongoDB and MongoDB -> Postgres validation runs must include both mapping layers before data movement starts:
- schema mapping for historical copy;
- live request mapping for dual-writes or write-log capture;
- response mapping for any target-read phase in blue/green, canary, or strangler patterns.
Use the PostgreSQL and MongoDB dual-mapping example as the reference shape for production validation. The example shows table-to-collection mapping, column-to-document-path mapping, relationship handling, index generation, live write templates, and response translation in both directions.
Strict Dual-Write Run
LogAndReplay Run
Validation Requirements
A production validation run should include:
- live reads and writes before, during, and after data movement;
- at least 100 unique request shapes for enterprise-style heterogeneous migrations;
- multi-GB source datasets for customer performance runs;
- complex schema features such as foreign keys, indexes, generated values, nullable values, empty strings, escaped text, timestamps, decimals, JSON or BSON, stored procedures, and trigger side effects;
- full planning output with discovered objects, fields, primary keys, indexes, foreign keys, routines, views, materialized views, sequences, extensions, user-defined types, size estimates, and complexity score;
- exact validation of source and target data after the workload is stopped for a final parity scan;
- archived run artifacts for later benchmark comparison.
Observability
Every run should preserve:
- full migration duration;
- sync duration;
- stage timings;
- historical copy throughput;
- live read and write counts;
- request errors and reconnects;
- write-log captured, replayed, lag, and gap counts;
- final source and target parity validation.
Grafana dashboards should be opened with run-specific variables for migration ID, service migration UUID, interlay UUID, endpoint kind, listener, role, and run ID.