ZEKTOR.IO Docs

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 CaseExample
CachingCache database queries, API responses, session data
Session storageStore user sessions for web applications
Rate limitingTrack request counts with TTL-based expiry
Real-time leaderboardsSorted sets for ranking and scoring
Pub/Sub messagingReal-time event broadcasting between services
Job queuesBullMQ, Sidekiq, Celery task queues
Feature flagsFast 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

  1. Each write command is appended to the AOF file
  2. The file is periodically rewritten to keep it compact
  3. 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 3600

Monitoring memory

Check your memory usage from the Valkey CLI:

valkey-cli -h <your-host> -p 6379 -a <password> --tls INFO memory

Key metrics to watch:

MetricDescription
used_memoryTotal bytes allocated by Valkey
used_memory_rssBytes allocated by the OS to Valkey
used_memory_peakPeak memory usage since start
mem_fragmentation_ratioRatio of RSS to used_memory (ideally close to 1.0)

Data Types

Valkey supports all Redis data types:

TypeDescriptionCommon Commands
StringsSimple key-value pairsSET, GET, INCR, MGET
ListsOrdered collectionsLPUSH, RPUSH, LPOP, LRANGE
SetsUnordered unique valuesSADD, SMEMBERS, SINTER
Sorted SetsScored, ordered unique valuesZADD, ZRANGE, ZRANGEBYSCORE
HashesField-value mapsHSET, HGET, HGETALL
StreamsAppend-only log structuresXADD, XREAD, XRANGE
HyperLogLogProbabilistic cardinality countingPFADD, PFCOUNT
BitmapsBit-level operationsSETBIT, 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 100

Always 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 300

Use 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 queue

Monitor 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

TierMax 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

On this page