Core functionality
Redistill is a high-performance, in-memory key-value store that implements the Redis RESP protocol. It supports strings, counters and hashes with TTLs and a sharded internal architecture for concurrency.
- Protocol: Full RESP support, compatible with
redis-cliand Redis client libraries. - Storage: In-memory hash-based store, sharded (256+ shards, 2048 recommended).
- TTL: Automatic key expiration, lazy deletion and memory reclamation.
Supported commands
Data commands
-
SET key value [EX seconds | PX milliseconds] [NX | XX] [GET]– store values with optional TTL and conditional flags. GET key,DEL key [key ...],EXISTS key [key ...]MSET key value [key value ...],MGET key [key ...]KEYS pattern(blocking, use with caution),SCAN cursor [MATCH pattern] [COUNT n](non-blocking key scan).DBSIZE,FLUSHDB,FLUSHALL
Counter commands
INCR key,DECR keyINCRBY key n,DECRBY key n
Hash commands
HSET key field value [field value ...]HGET key fieldHGETALL key
Hashes are ideal for user profiles, configuration objects or product metadata, allowing efficient field-level updates without rewriting full JSON blobs.
TTL commands
EXPIRE key secondsTTL key,PTTL keyPERSIST key
Server commands
PING,AUTH password,INFOCONFIG GETandCOMMANDstubs for client compatibility.
Security
Security features are designed to be production-ready while keeping configuration simple.
- Password authentication via
AUTHandREDIS_PASSWORD/ config file. - TLS/SSL encryption using Rustls, with certificate paths configured in
[security]. - Connection management: max connection limits, connection rate limiting and timeouts.
Memory & eviction
Redistill tracks memory usage in real time and supports configurable eviction policies when a memory limit is set.
max_memory(0 = unlimited) controls the upper bound.- Eviction policies:
- allkeys-lru – least recently used keys (recommended default)
- allkeys-random – random eviction, faster but less targeted
- allkeys-s3fifo – modern S3-FIFO algorithm with better hit rates on many workloads
- noeviction – reject new writes when memory is full
Reliability & monitoring
- Graceful shutdown with signal handling, connection draining and final statistics.
- Health checks via optional HTTP endpoint for readiness and liveness probing.
-
Metrics: total and active connections, rejected connections, commands processed, memory usage,
evicted keys, uptime and more exposed via
INFOand the health endpoint.
Optional snapshot persistence
For maximum performance, Redistill disables persistence by default. When you need warm restarts, you can enable snapshot-based persistence:
SAVE– synchronous snapshot.BGSAVE– background snapshot that doesn't block request handling.LASTSAVE– timestamp of last successful save.
[persistence]
enabled = false
snapshot_path = "redistill.rdb"
snapshot_interval = 300
save_on_shutdown = true
This is intentionally snapshot-only (RDB-like). It is not designed for real-time durability; some data between snapshots can be lost on crash or restart.
Intentionally not implemented
To keep the core tight and fast, several Redis features are explicitly out of scope:
- Write-ahead logging (AOF).
- Replication and clustering.
- Complex data structures like lists, sets, sorted sets, streams, bitmaps, HyperLogLog.
- Pub/Sub.
- Transactions (
MULTI/EXEC). - Lua scripting.
- Redis modules.
Many of these appear on the roadmap as potential future additions if they can be implemented without compromising core performance goals.
Use case fit & comparison
Where Redistill excels
- Session storage with high read/write ratios and TTLs.
- API response caching for JSON/HTML payloads.
- Rate limiting and counters where occasional data loss is acceptable.
- Real-time leaderboards and metrics that can be rebuilt from a primary store.
Comparison to Redis
| Feature | Redistill | Redis |
|---|---|---|
| Protocol | RESP (Redis-compatible) | RESP |
| Throughput (single instance) | ≈9.07M ops/s | ≈2.03M ops/s |
| p50 latency | ≈0.48 ms | ≈2.38 ms |
| Data types | String, counters, hashes | Full set (lists, sets, sorted sets, etc.) |
| Persistence | Optional snapshots | AOF + RDB |
| Replication & clustering | Not built-in (client-side sharding) | Built-in replication and Redis Cluster |
In short: use Redistill when you want the fastest possible Redis-compatible cache, and reach for Redis or Dragonfly when you need full data structures, clustering, or strong persistence guarantees.