Engula is built on the Redis Server 7.2 codebase: commands, Lua, transactions and Redis modules (RediSearch, RedisJSON, etc.) are all supported, with a measured pass rate of 99.40% on the official test suite (4300+ subtests match, every difference disclosed). This is the core difference from "rewrite-style" alternatives.
No. Attach Engula as a replica of your existing Redis, let it catch up, then switch traffic over.
No. Engula speaks the standard Redis protocol, runs self-hosted, and your data stays in your hands — you can switch back to stock Redis at any time.
The data plane is never affected — no downtime, no data loss. Expiry only restricts management operations such as further cluster scale-out; reads/writes, replication and failover continue as normal.
They cost more, and your data and control sit on the vendor’s side; Engula is self-hosted, saves memory and avoids lock-in — your data always stays in your environment.
Engula is a pure in-memory database kernel built for Redis/Valkey migration scenarios, keeping protocol semantics highly consistent with existing clients, proxies and common ops tooling.
Its core difference is the underlying memory engine: more compact metadata, object encoding and transparent compression lower the per-key overhead, while preserving the Redis-style data model and operating conventions.
In most production scenarios the savings range from 40% to 75%. It depends on the mix of data structures, average key/value size and TTL distribution. You can import your own RDB snapshot with ValueSight and get a more accurate memory comparison within 5 minutes.
Engula lowers memory through real-time compression/decompression, which consumes some CPU. At the single-thread tier (ioThreads=1) throughput is 0.83–0.86× of Redis; from 2 I/O threads up Engula pulls ahead and scales with cores — full matrix on the live proof page. If your workload is CPU-bound rather than memory-bound, the benefit is relatively limited.
Both are supported. Engula is compatible with the Redis Cluster protocol and works directly with your existing cluster topology, with no need to adjust your sharding strategy. Sentinel configurations can be reused directly as well.
The Redis 7.2 ACL permission system is supported, and the transport layer supports TLS encryption. Encryption of the RDB persistence file is a roadmap capability — contact the technical team for the latest status.
Engula aligns with Redis’s wire protocol and command behavior. The current public verification baseline is the official Redis 7.2.11 test suite (runtest, moduleapi, sentinel and cluster): 4300+ subtests match (99.40%), with the reasons and impact of every difference disclosed item by item on the live proof page.
Engula offers a Developer Edition and Enterprise. The Developer Edition is free forever, with up to 6 Engula nodes (any master/replica ratio) and unlimited memory per instance. Enterprise targets larger scale and production, and includes enterprise support, an SLA and a formal contract.
Engula’s modular design keeps the storage integration points highly isolated, allowing it to align with new Redis/Valkey versions faster. The current public verification baseline is Redis 7.2.11, and migration toward Valkey 8/9 is underway.
Yes. Engula’s background save process always forks while the server is not in the middle of executing a command, so commands that are atomic in memory are also atomic from the disk-snapshot perspective.
Engula reuses the Redis/Valkey I/O-thread model. With io-threads enabled, client read/write work is offloaded to separate threads so the main thread can focus on command execution.
Within the main thread and each I/O thread, Engula adds lightweight, interruptible coroutines. Background tasks are split into small coroutines and scheduled by priority to reduce their impact on foreground tail latency.
Engula supports up to 2^32 keys and has been tested at a scale of at least 250 million keys per instance. Each Hash, List, Set and Sorted Set can hold up to 2^32 elements; the practical limit is usually determined by available memory.
If you use keys with TTLs, this is expected. On the first sync with a replica, the primary generates an RDB file; the RDB does not include keys that have logically expired on the primary but are still held in memory.
When the replica loads the primary’s RDB, those logically expired keys are not loaded. So when there are many TTL keys, the replica often shows a smaller key count. The datasets are logically consistent; the difference comes mainly from counting semantics and reclamation timing.
This FAQ is updated regularly. If your question isn’t covered, contact support@engula.com.