In‑memory design with full Redis/Valkey wire‑protocol compatibility (RESP2/RESP3, PSYNC, Cluster/Sentinel).
Compact metadata and object encoding reduce per‑key overhead; HybridLog uses log‑structured, immutable blocks for transparent in‑memory compression.
Sub‑millisecond foreground latency; background maintenance is fine‑grained and interruptible to preserve tail‑latency.
Practical outcome on internet workloads: ~40–60% memory reduction at fleet scale while preserving expected Redis semantics.
Storage engine: Engula replaces the in‑memory object storage with a compact, compressible engine while keeping command behavior and protocol intact.
Trade‑off: Controlled CPU is spent on real‑time compression/decompression to save RAM; reads/writes remain in memory with sub‑ms latency.
Recovery: Log‑structured memory layout aligns with snapshots, enabling substantially faster cold‑start and full sync.
Operations: Modular integration points allow rapid alignment with new Valkey releases without client changes.
Yes, the Engula background saving process is always forked when the server is outside of the execution of a command, so every command reported to be atomic in RAM is also atomic from the point of view of the disk snapshot.
Engula scales across multiple CPUs/cores in a way that is very similar to Redis/Valkey:
I/O threads for network offload: Engula reuses the Redis/Valkey threading model. Enabling and scaling I/O threads offloads client read/write work to separate threads, so the main thread can focus on command execution. Configure io-threads as you would in Redis/Valkey.
Coroutines inside each thread: Inside the main thread and each I/O thread, Engula adds lightweight, interruptible coroutines. Background tasks (such as periodically compressing and replacing blocks in the Immutable Zone) are broken down into small coroutines that run within existing Redis/Valkey threads, are scheduled with priority, and are preferentially dispatched to non‑main I/O threads when possible.
Configuration compatibility: Using multiple CPUs with Engula is configured the same way as with Redis/Valkey. Enable and tune io-threads, and Engula leverages available cores through I/O threading and coroutine‑based background work.
Engula can handle up to 2^32 keys and has been tested to handle at least 250 million keys per instance.
Every Hash, List, Set, and Sorted Set can hold up to 2^32 elements.
In practice, limits are determined by available memory.
If you use keys with limited time to live (expires), this is normal behavior:
The primary generates an RDB file on the first synchronization with the replica.
The RDB file will not include keys that are already expired on the primary but are still in memory.
These keys are still in the memory of the primary, even if logically expired. They are not considered existing, and their memory will be reclaimed later, either incrementally or explicitly on access. While not logically part of the dataset, they are counted in INFO and DBSIZE.
When the replica reads the RDB file generated by the primary, this set of logically expired keys is never loaded.
As a result, users with many expiring keys often see fewer keys on replicas. Logically, the primary and replica datasets are equivalent; differences are transient accounting artifacts.
Note: This FAQ is continuously updated. If you have questions not covered here, please contact support@montplex.com.