Valkey
Managed Valkey instances on Zektor.io — a high-performance, Redis-compatible key-value store with TLS, persistence, and real-time monitoring.
Overview
Valkey is a high-performance, open-source key-value store and a drop-in replacement for Redis. Zektor.io provides fully managed Valkey instances with TLS encryption, AOF persistence, and real-time monitoring.
Key Features
- Redis-compatible — Use any Redis client library, no code changes needed
- TLS by default — All connections are encrypted
- AOF persistence — Data survives instance restarts
- Sub-millisecond latency — Optimized for caching and real-time data
- Dedicated resources — No noisy neighbors, guaranteed RAM allocation
Use Cases
| Use Case | Example |
|---|---|
| Caching | Cache database queries, API responses, session data |
| Session storage | Store user sessions for web applications |
| Rate limiting | Track request counts with TTL-based expiry |
| Real-time leaderboards | Sorted sets for ranking and scoring |
| Pub/Sub messaging | Real-time event broadcasting between services |
| Job queues | BullMQ, Sidekiq, Celery task queues |
| Feature flags | Fast key-value lookups for feature toggles |
Data Persistence
Zektor.io Valkey instances use Append-Only File (AOF) persistence by default. This means:
- Every write operation is logged to disk
- Data survives instance restarts and reboots
- Minimal performance impact compared to RDB snapshots
How AOF works
- Each write command is appended to the AOF file
- The file is periodically rewritten to keep it compact
- On restart, Valkey replays the AOF to restore state
Note: Valkey is still primarily an in-memory store. All data must fit in your instance's allocated RAM. AOF provides durability, not additional storage.
Memory Management
Understanding memory usage
Your Valkey instance's RAM is shared between:
- Data — Keys, values, and internal data structures
- Client buffers — Memory used by connected clients
- AOF buffers — Memory used during AOF rewrite operations
- Overhead — Internal Valkey metadata and fragmentation
As a rule of thumb, plan for your actual data to use about 80% of the allocated RAM, with 20% reserved for overhead.
Eviction policies
When memory is full, Valkey uses an eviction policy to make room for new data. The default policy is noeviction, which returns errors when memory is full.
If you're using Valkey primarily as a cache, consider setting a TTL on all keys:
# Set a key with 1-hour expiry
SET mykey "myvalue" EX 3600Monitoring memory
Check your memory usage from the Valkey CLI:
valkey-cli -h <your-host> -p 6379 -a <password> --tls INFO memoryKey metrics to watch:
| Metric | Description |
|---|---|
used_memory | Total bytes allocated by Valkey |
used_memory_rss | Bytes allocated by the OS to Valkey |
used_memory_peak | Peak memory usage since start |
mem_fragmentation_ratio | Ratio of RSS to used_memory (ideally close to 1.0) |
Data Types
Valkey supports all Redis data types:
| Type | Description | Common Commands |
|---|---|---|
| Strings | Simple key-value pairs | SET, GET, INCR, MGET |
| Lists | Ordered collections | LPUSH, RPUSH, LPOP, LRANGE |
| Sets | Unordered unique values | SADD, SMEMBERS, SINTER |
| Sorted Sets | Scored, ordered unique values | ZADD, ZRANGE, ZRANGEBYSCORE |
| Hashes | Field-value maps | HSET, HGET, HGETALL |
| Streams | Append-only log structures | XADD, XREAD, XRANGE |
| HyperLogLog | Probabilistic cardinality counting | PFADD, PFCOUNT |
| Bitmaps | Bit-level operations | SETBIT, GETBIT, BITCOUNT |
Best Practices
Use appropriate data structures
Choose the right data type for your access pattern:
# Bad: storing structured data as JSON strings
SET user:1 '{"name":"Alice","email":"[email protected]","score":100}'
# Good: use a Hash for structured data
HSET user:1 name "Alice" email "[email protected]" score 100Always set TTLs on cache keys
Prevent unbounded memory growth by setting expiration on keys:
# Set with expiry
SET cache:api:response "..." EX 300 # 5 minutes
# Add expiry to existing key
EXPIRE cache:api:response 300Use pipelining for bulk operations
Reduce round-trip latency by batching commands:
// Node.js with ioredis
const pipeline = redis.pipeline();
for (let i = 0; i < 1000; i++) {
pipeline.set(`key:${i}`, `value:${i}`);
}
await pipeline.exec();Use key prefixes and naming conventions
Organize your keyspace with consistent naming:
app:users:1:profile # User profile
app:users:1:sessions # User sessions
app:cache:api:products # API cache
app:queue:emails # Job queueMonitor eviction and memory
If you see evicted_keys increasing, you either need:
- A larger instance tier
- Shorter TTLs on your keys
- To review whether all stored data is necessary
Connection Limits
| Tier | Max Clients |
|---|---|
| Starter (128MB) | 128 |
| Standard (256MB) | 256 |
| Pro (512MB) | 512 |
| Business (1GB) | 1024 |
Differences from Redis
Valkey is a community fork of Redis and is fully compatible with Redis clients and protocols. Key differences:
- Open-source license — Valkey uses the BSD-3-Clause license (no SSPL restrictions)
- Community-driven — Governed by the Linux Foundation
- Active development — Continued improvements and new features
- Full compatibility — All Redis clients, libraries, and tools work with Valkey
You can use redis-cli, ioredis, redis-py, go-redis, and any other Redis client library with Zektor.io Valkey instances.
Next Steps
- Getting Started — Deploy your first Valkey instance
- Connecting — Connection strings and client libraries
- Monitoring — Track cache performance
- Scaling — Upgrade to a larger tier
- Pricing — Valkey tier pricing