Redis Differences

FrogDB is wire-compatible with Redis via RESP2/RESP3. Any Redis client library works without modification. This page documents only the differences — for standard Redis behavior, see the Redis documentation.

This page compares FrogDB 0.1.0 against Redis 8.x (open-source).

Architecture

	Redis 8.x	FrogDB
Threading	Single-threaded command processing (I/O threads for socket reads/writes)	Shared-nothing multi-threaded (sharded workers)
Storage engine	In-memory with RDB/AOF	In-memory with RocksDB WAL
Cluster coordination	Gossip protocol	Raft consensus with orchestrated control plane
Configuration format	`redis.conf` (custom)	`frogdb.toml` (TOML)
Allocator	jemalloc	jemalloc
Lua version	5.1	5.4

Persistence

FrogDB uses RocksDB instead of RDB/AOF. This means:

No RDB/AOF files — data is stored in RocksDB SST files with a WAL
No SAVE/BGSAVE semantics — use BGSAVE to trigger a forkless snapshot (no fork() overhead)
No BGREWRITEAOF — RocksDB manages WAL compaction automatically
Durability modes: async, periodic, sync (not appendfsync always/everysec/no)
RDB files from Redis cannot be imported directly

See Persistence for configuration details.

Configuration

FrogDB uses TOML instead of redis.conf. Key mappings:

redis.conf	frogdb.toml
`bind 0.0.0.0`	`server.bind = "0.0.0.0"`
`port 6379`	`server.port = 6379`
`requirepass secret`	`security.requirepass = "secret"`
`maxmemory 1gb`	`memory.maxmemory = 1073741824`
`maxclients 10000`	`server.max-clients = 10000`
`appendonly yes`	`persistence.enabled = true`
`appendfsync everysec`	`persistence.durability-mode = "periodic"`
`save 900 1`	`snapshot.snapshot-interval-secs = 900`

Environment variables use FROGDB_ prefix with double underscores for nesting: FROGDB_SERVER__PORT=6380.

See Configuration Reference for all options.

Clustering

FrogDB uses Raft consensus instead of Redis Cluster’s gossip protocol:

Orchestrated control plane — no CLUSTER MEET, topology managed via admin API
Raft-based leader election — deterministic failover, no split-brain
Two-level sharding — cluster hash slots (16384) mapped to internal shard workers
CLUSTER BUMPEPOCH is not supported
Replica migration is manual (not automatic)

See Clustering for details.

Cross-Slot Operations

FrogDB partitions keys across internal shards (even in standalone mode). This affects multi-key operations.

Multi-key commands (MGET, MSET, etc.) require all keys to hash to the same slot, or they return -CROSSSLOT. This applies in cluster mode. In standalone mode, cross-slot operations work by default via scatter-gather.

Set server.allow-cross-slot-standalone = true to explicitly allow cross-slot operations in standalone mode.

Transactions

MULTI/EXEC requires all keys within the same hash slot (cluster mode)
In standalone mode, cross-shard transactions use VLL for atomicity
WATCH uses per-key version tracking

Blocking Commands

BLPOP, BRPOP, BLMOVE etc. require all keys on the same shard
Cross-shard blocking returns -CROSSSLOT

Lua Scripting

Strict Key Validation

FrogDB enforces that all keys accessed in a script are declared via KEYS[]. Accessing undeclared keys returns an error (Redis allows this but discourages it).

-- This works
EVAL "return redis.call('GET', KEYS[1])" 1 mykey

-- This errors in FrogDB (works in Redis)
EVAL "return redis.call('GET', 'mykey')" 0

Single-Shard Requirement

All keys in a script must hash to the same shard. Multi-shard scripts are not supported.

Other Differences

redis.setresp() is not supported
Lua 5.4 (not 5.1) — minor syntax differences for edge cases

Pub/Sub

Standard PUBLISH/SUBSCRIBE and pattern subscriptions (PSUBSCRIBE) work identically to Redis.

Differences in cluster mode:

Regular PUBLISH: broadcasts to all cluster nodes, same as Redis
Sharded Pub/Sub (SSUBSCRIBE/SPUBLISH): messages are routed to the shard owning the channel’s hash slot, consistent with Redis Cluster behavior
Subscription limits: configurable via blocking.max-subscriptions-per-client (Redis has no built-in per-client limit)
Cluster-wide fan-out: regular Pub/Sub messages are forwarded across cluster nodes so subscribers on any node receive them

In standalone mode, Pub/Sub behavior is identical to Redis.

Database Model

FrogDB uses a single database (db0). SELECT with non-zero index returns an error. MOVE and SWAPDB are not supported.

Not Supported

Command/Feature	Reason
`SELECT` (non-zero)	Single database model
`MOVE`, `SWAPDB`	Single database model
`MODULE *`	No module architecture
`CONFIG REWRITE`	Changes via CONFIG SET are transient
`BGREWRITEAOF`	RocksDB manages WAL lifecycle
`SYNC`	Legacy; use PSYNC
`DEBUG SEGFAULT/RELOAD/CRASH-AND-RECOVER`	Unsafe debug subcommands disabled
`redis.setresp()` in Lua	Not implemented
Diskless replication	Not yet supported

Tiered Storage

FrogDB supports two-tier hot/warm storage as an alternative to eviction. When memory pressure occurs with the tiered-lru or tiered-lfu eviction policies:

Instead of deleting keys, FrogDB serializes values to RocksDB (the “warm” tier)
The key metadata remains in memory, but the value is stored on disk
Reads transparently deserialize the value back to memory (promotion)

This requires persistence.enabled = true and a tiered-lru or tiered-lfu eviction policy. See Configuration Reference for settings.

No Redis equivalent — open-source Redis only supports eviction (keys are deleted when memory is full). Redis Enterprise offers a commercial “Auto Tiering” feature that tiers data between DRAM and NVMe, but this is not available in open-source Redis.