Exodus Migrations
Exodus is Eden's migration product. It uses Eve endpoints, interlays, telemetry, and workflow state to move live database workloads from a source system to a target system while keeping validation and rollback in the operator's hands.
Use Exodus when a database migration cannot be treated as a one-time copy. The product is designed for migrations that need staged testing, traffic observation, live validation, dual operation, and rollback before commit.
What Exodus Does
Exodus puts Eve in the migration path:
Applications
|
v
Exodus interlay and migration workflow
|
+-- Source database
+-- Target database
+-- Observability and validationThe source remains available until the operator commits the migration. The target is prepared, backfilled, tested, compared, and promoted through explicit workflow phases.
Migration Phases
The customer-facing migration model has seven phases.
| Phase | Traffic path | Purpose |
|---|---|---|
| Pre-test | Applications still talk directly to source; traffic is copied to Exodus in parallel. | Prove that Exodus can observe production-shaped traffic without changing the authoritative path. |
| Analyze | Applications cut over to Exodus; Exodus forwards to source. | Measure workload shape, compatibility, throughput, command mix, and migration risk. |
| Compare | Source remains authoritative. | Mirror safe operations to target and compare results without serving target responses. |
| Test | Exodus uses the observed workload and target configuration. | Run validation, smoke tests, compatibility checks, and rollback rehearsal. |
| Migrate | Applications continue through Exodus. | Move historical data while coordinating live writes according to the selected strategy. |
| Rollback | Applications continue through Exodus. | Return traffic to source when validation, latency, or business checks fail. |
| Commit | Target becomes authoritative. | Complete the migration and retire source only when operational criteria are met. |
Supported Endpoint Families
| Endpoint family | Product status in docs | Notes |
|---|---|---|
| Redis and Valkey-compatible systems | Guided workflow available | Includes Redis Cloud, ElastiCache, MemoryDB, Azure Cache, Valkey, and compatible systems. |
| PostgreSQL | Early access planning docs | Requires transaction-aware cutover, schema-aware comparison, and careful handling of COPY, prepared statements, triggers, and side effects. |
| MongoDB | Preview planning docs | Requires document comparison, change stream awareness, session handling, and provider compatibility checks. |
See Migrations for the operator runbook and endpoint-specific docs for Redis, PostgreSQL, and MongoDB setup details.
Core Objects
| Object | Role in Exodus |
|---|---|
| Source endpoint | The current authoritative database. |
| Target endpoint | The destination database that will become authoritative after commit. |
| Interlay | The listener applications connect to so Exodus can forward, mirror, compare, roll back, or cut over traffic. |
| Workflow run | The guided state machine for setup, validation, approval, execution, retry, and completion. |
| Migration record | The lower-level migration object that stores strategy, runtime state, tests, data movement, and compatibility information. |
| Telemetry stream | Events, metrics, queue depth, divergence, latency, and error details used by dashboards and operators. |
Operator Responsibilities
Before a production migration, the operator should:
- Inventory source and target connection details, protocol versions, TLS settings, credentials, and provider limits.
- Confirm application traffic can be redirected to an interlay.
- Establish rollback criteria before execution.
- Confirm dashboards or SSE subscribers receive migration events.
- Run pre-test and analyze long enough to capture representative workload behavior.
- Validate target sizing, command compatibility, and provider feature differences.
- Keep source available until commit is complete and business owners approve decommissioning.
Strategy Decisions
The Redis workflow exposes several strategy decisions:
| Decision | Why it matters |
|---|---|
| Migration strategy | Controls whether the run behaves as big-bang, canary, or blue/green. |
| Conflict policy | Controls how backfill handles existing target keys. |
| Data movement mode | Controls ordinary source-to-target copy versus bidirectional repair behavior. |
| Write consistency | Controls whether source, target, either side, or both sides determine write success during dual operation. |
| TTL preservation | Controls whether Redis key expiration metadata is retained. |
| Manual approval | Keeps execution behind an explicit human checkpoint. |
Keep manual approval enabled for production. Automated runs are useful for repeatable test environments, but production migrations need a named decision owner.
Observability
Exodus should be monitored with:
- Phase and workflow status.
- Source and target health.
- Data movement progress.
- Mirrored write latency.
- Replay queue depth.
- Divergence count and unresolved keys.
- Compatibility warnings and critical issues.
- Rollback readiness and commit status.
The migration dashboard should make it clear which system is authoritative at every phase.