Live proof · PROOF · REDIS 7.2.11

Run the official Redis 7.2.11 runtest directly

No modified test cases, no separate assertion set. We run the official Redis 7.2.11 test suite directly; engula passes — / — subtests (—). Every log line is publicly verifiable on the dashboard.

The failing items cover internal-representation / monitoring-field differences, boundary-behavior differences and a few high-priority fixes; each can be expanded for its reason and impact.

Subtests covered

—

redis 7.2.11 tests/

Passed

—

—% consistent with redis behavior

Failed

—

Reason / impact per item in the drawer

Last run #— · took — · View the redis@7.2.11 test source ↗

Live dashboard →View full results ↗

Compatibility

—

Failures

—

Reasons and impact disclosed per item

RDB path

13.7x / 6.1x

BGSAVE 3.71s vs 50.86s · LOAD 2.39s vs 14.62s · fixed release baseline

Live run

—

Runs automatically every 1–2 min

Four independent runtest suites (Run test / Module API / Sentinel / Cluster); their total equals the RUNTEST overview below.

RUNTEST overview

Run the official Redis 7.2.11 runtest item by item

Covers every test unit under redis tests/; only failing subtests are listed, each with its reason / impact.Click any button for details.

— / —subtests passed · —

— · vs —

—

Full report page ↗

Client compatibility

Mainstream client SDKs connect directly and behave like Redis

Covers Java / Python / Go / Node.js; each SDK runs its own official/community-maintained compatibility suite.

—

Performance matrix

Multi-thread × multi value-size, measured against Redis in the same environment

Dimensions = read/write ratio × ioThreads × value length; the ratio is shown as read:write. Each cell shows engula / redis actual throughput (ops/s), P99 latency (ms) and the ratio.

Read/write ratio 8:2

read:write · read 80% / write 20%

ioThreads · 1 threads

16 B

—

32 B

—

64 B

—

128 B

—

ioThreads · 2 threads

16 B

—

32 B

—

64 B

—

128 B

—

ioThreads · 4 threads

16 B

—

32 B

—

64 B

—

128 B

—

ioThreads ↓ / value length (B) →	16 B	32 B	64 B	128 B
1 threads	—	—	—	—
2 threads	—	—	—	—
4 threads	—	—	—	—

Click any cell for p99 / p99.9 / memory footprint / CPU details; the bottom button opens the public proof dashboard with the history of the last 10 runs.

RDB SAVE / LOAD / BGSAVE

Real on-disk time for cold start and maintenance windows

Dataset size × data type = 9 cells. SAVE / LOAD each get a matrix; BGSAVE separately covers the fork window and peak memory.

SAVE on-disk time

Blocking RDB write · higher is better (how many times faster engula is vs Redis)

Dataset · 1G dataset

string

—

hash

—

set

—

Dataset · 4G dataset

string

—

hash

—

set

—

Dataset · 8G dataset

string

—

hash

—

set

—

Dataset ↓ / Data type →	string	hash	set
1G dataset	—	—	—
4G dataset	—	—	—
8G dataset	—	—	—

LOAD restart time

Restoring memory from the RDB file on cold start · determines the failure-recovery / scale-up window

Dataset · 1G dataset

string

—

hash

—

set

—

Dataset · 4G dataset

string

—

hash

—

set

—

Dataset · 8G dataset

string

—

hash

—

set

—

Dataset ↓ / Data type →	string	hash	set
1G dataset	—	—	—
4G dataset	—	—	—
8G dataset	—	—	—

Click any cell for LOAD time / RDB file size / memory footprint details.

BGSAVE fork-tree memory peak (1 / 4 / 8 GB)

read/write 8:2; peak = the physical memory actually held by the parent and child processes during the BGSAVE fork (fork-tree PSS).

peak/used is the share of pages copied-on-write during the fork: 1.0× means no extra copies, 2.0× means nearly all dataset pages were copied. Engula’s short fork window copies few pages and stays near 1.0×; Redis’s long window approaches 2.0×.

1GB · 5M keys × 128B · read/write 8:2

BGSAVE time

—faster

engula —·redis —

Peak fork-tree memory

—leaner

engula —·redis —

spike ratio (peak / used)

engula — · redis —

4GB · 20M keys × 128B · read/write 8:2

BGSAVE time

—faster

engula —·redis —

Peak fork-tree memory

—leaner

engula —·redis —

spike ratio (peak / used)

engula — · redis —

8GB · 40M keys × 128B · read/write 8:2

BGSAVE time

—faster

engula —·redis —

Peak fork-tree memory

—leaner

engula —·redis —

spike ratio (peak / used)

engula — · redis —

Replication · bring-up & reconnect

Faster replication, steadier reconnect

A replica joining needs a full resync, and a reconnect collides with BGSAVE — the moments most likely to stretch the sync window and spike the primary’s memory and replication buffers. The two measured scenarios below compare Engula and Redis right there.

Single-replica full-sync

Primary

Same logical data

10.37M keys · 8GB

Full-sync (RDB)

New replica

Joins & catches up

Consistency verified

Full-sync time4.98× faster

engula9.17s

redis45.66s

RDB file size1.44× smaller

engula4651 MB

redis6714 MB

01 — Full-sync

Same data, the replica catches up faster

A new replica full-resyncs the same dataset; comparing sync time, RDB size and memory usage.

10.37M keys8 GB memory cap

Faster sync: 9.17s vs 45.66s (4.98×), a shorter window while the replica is behind.
Less data to ship: RDB 4651 MB vs 6714 MB (1.44×), cheaper to write and replicate.
Lower memory, same data: 5058 MB (59%) vs 8551 MB (99.5%).

Reconnect storm (COW)

16 clients

8:2 read/write

target ~50k QPS

Write

Primary

Single BGSAVE

Full-sync

2 replicas

Reconnect together

BGSAVE memory peak2.50× lower

engula5285 MB

redis13205 MB

Replication buffer peak7.18× lower

engula27.9 MB

redis200.2 MB

02 — Reconnect storm

Under the same single BGSAVE, less pressure on the primary

2 replicas reconnect while 16 clients keep writing during BGSAVE; comparing peak memory and replication buffers under the same BGSAVE.

10.36M keys8 GB memory cap2 replicas16 clients · 8:2 read/write

Lower memory peak: 5285 vs 13205 MB (2.50×), far less extra memory during BGSAVE.
Lower replication buffers: 27.9 vs 200.2 MB (7.18×), much less pile-up on the primary.
Shorter sync window: 12.61s vs 54.19s (4.30×), the storm converges faster.

Conditions: compressible dataset over loopback, a single BGSAVE on both sides; RDB size is measured as the on-disk file.

High availability + platform

Cluster, replication, failover, platform compatibility

HA and platform-layer cases reuse Redis’s official topology tests directly. Each comes with PASS/FAIL and key metrics —click for details.

High availability / cluster

—

Platform compatibility / stability

—

Live proof · LIVE

Live verification dashboard

Every 1–2 minutes we automatically run a round of compatibility, performance, high-availability, RDB and other test suites. The stdout stream is fully public, line by line.

99.40% on the official test suiteFailure reasons disclosedRuns automatically every 1–2 min

proof@engula — — · —IDLE

loading — logs ...

Latest round— loadingIn progress0View last result →Run history →

All results are publicly traceable at /proof— you are welcome to verify them.

Transparency footnote

Every result is reproducible by you

The test code uses the 7.2.11 tag from Redis’s official repository. The full output (stdout) of every run is kept on the public dashboard for 24+ hours, so anyone can verify them anytime.

Test machine: —
engula version: —
Baseline: —
Data collection: runtest direct, unmodified, same source code
Test source: github.com/redis/redis@7.2.11/tests ↗
Full dashboard: Full dashboard ↗