QUEUES & CACHING
Queues, caching & app state
A Redis-compatible engine inside your database — cache, job queues, and pub/sub without a second system.
THE STATUS QUO
Postgres for truth, Redis for speed, a queue for jobs: three systems, three failure modes, and the eternal cache-invalidation bug between them.
HOW EzraDB DOES IT
Point ioredis, redis-py, or redis-cli at port 6379 — strings, hashes, lists, sets, and sorted sets, no client changes.
XADD / XREADGROUP / XACK give background jobs real delivery semantics — unmodified BullMQ passes its test suite against EzraDB.
Your existing rate limiters and atomic check-and-set scripts run as-is.
SUBSCRIBE, BLPOP, BZPOPMIN — the coordination primitives your workers already speak.
Author job queues in typed TypeScript — pgforge compiles claim/retry/backoff, dead-lettering, and recurring jobs to run inside the database.
The cache lives beside the source of truth — one deployment, one backup story, no drift between "fast" data and real data.
Durable, tiered storage for KV data beyond RAM.
*In development — not yet production-ready.
IN PRACTICE
Delete a system from your architecture diagram — the red one.
# point any Redis client at EzraDB (opt-in listener, port 6379)
redis-cli -p 6379 XADD jobs '*' task resize_image id 42
redis-cli -p 6379 XREADGROUP GROUP workers w1 COUNT 10 STREAMS jobs '>'
redis-cli -p 6379 XACK jobs workers 1719900000000-0
MORE WAYS TEAMS USE EzraDB