Skip to main content

​
Overview

PropertyValue
Engine IDredis
Wire ProtocolRESP (Redis Serialization Protocol)
ClassifierCommand-based (static lookup table, ~155 commands)
ShadowDocker redis:<version> (version-matched)
AuthPassword + Redis 6+ ACL (username + password)
Redis uses the RESP protocol with a command-based classifier. Delta tracking works at the key level — key prefixes (the portion before the first :) serve as “tables” and full key names serve as “primary keys”. All Redis data types are supported: strings, hashes, lists, sets, sorted sets, streams, HyperLogLog, bitmaps, and geo. Connection Parameters:
FieldDescriptionDefault
hostRedis host—
portRedis port6379
usernameUsername (Redis 6+ ACL)—
passwordPassword—
db_numberDatabase number0
sslEnable SSL/TLSfalse
mori init --from "redis://:password@host:6379/0"
mori init --from "redis://myuser:mypass@host:6379/0"  # ACL auth

​
Differences from PostgreSQL

Redis is fundamentally different from SQL databases. The copy-on-write model is adapted as follows:
  • Key-level delta tracking — Instead of (table, pk) pairs, Redis tracks (prefix, key) pairs. Reads check per-key: delta keys route to shadow, tombstoned keys return nil/empty, clean keys route to prod.
  • Hydration via DUMP/RESTORE — Instead of SELECT/INSERT, Redis hydrates by serializing the key from prod (DUMP) and deserializing to shadow (RESTORE), preserving data type, TTL, and internal encoding.
  • MULTI/EXEC transactions — Redis transactions queue commands and execute atomically. Mori buffers queued commands, hydrates write keys at EXEC time, forwards to shadow within MULTI, and tracks deltas. WATCH invalidation triggers rollback of staged deltas.
  • SCAN merging — Two-phase cursor merging: Phase 0 scans prod (filtering tombstoned and delta keys), Phase 1 scans shadow for delta/new keys. Cursor uses bit 63 as a phase flag.
  • Multi-key reads — MGET routes per-key (batched to shadow/prod). EXISTS counts per-key across backends. SDIFF/SINTER/SUNION hydrate all source keys to shadow and execute there.
  • Pub/Sub fan-in — SUBSCRIBE/PSUBSCRIBE is forwarded to both prod and shadow. Messages from either backend are multiplexed to the client. PUBLISH is blocked (matching PostgreSQL’s treatment of NOTIFY).
  • Lua scripting — EVAL/EVALSHA hydrate declared keys, execute on shadow, and track all declared keys. EVALRO/EVALSHA_RO also route through merged read with hydration for correctness.
  • FLUSHDB/FLUSHALL — Marks the database as fully shadowed. All subsequent reads go to shadow only.
  • RESP3 normalization — If upstream Redis responds with RESP3 types, the proxy normalizes them to RESP2. HELLO command is intercepted to force RESP2.
  • Tombstone responses — Returns type-appropriate nil/empty for tombstoned keys (null bulk string for GET, empty array for HGETALL, integer 0 for LLEN, -2 for TTL, “none” for TYPE).

​
Known Limitations

  • Blocking commands (BLPOP, BRPOP, etc.) only see shadow state — pushes from non-Mori clients to prod are not visible.
  • PUBLISH is blocked (returns error — would affect production subscribers).
  • No savepoint support (Redis MULTI/EXEC is atomic, no partial rollback).
  • Functions aren’t supported yet because it’s really hard to determine if the function is non-mutating or not.