Features

Redistill implements a focused subset of the Redis feature set, tuned for high-performance key-value and hash workloads, with security, monitoring and optional persistence built in.

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-cli and 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 key
  • INCRBY key n, DECRBY key n

Hash commands

  • HSET key field value [field value ...]
  • HGET key field
  • HGETALL 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 seconds
  • TTL key, PTTL key
  • PERSIST key

Server commands

  • PING, AUTH password, INFO
  • CONFIG GET and COMMAND stubs for client compatibility.

Security

Security features are designed to be production-ready while keeping configuration simple.

  • Password authentication via AUTH and REDIS_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 INFO and 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.