Before you start: migrate from KeyDB to KiviDB

Before you start. Migrate to KiviDB: Move from Redis, Valkey, ElastiCache, Redis Cloud, Aiven, Aerospike, Hazelcast and more: getting the data out, loading it

Run these on each KeyDB server:

export REDISCLI_AUTH="$KEYDB_PASSWORD"
K="keydb-cli -h keydb.internal -p 6379"     # redis-cli works too

$K INFO server | grep -E 'redis_version|executable'
$K INFO keyspace
$K INFO memory | grep -E '^used_memory_human|maxmemory_human|maxmemory_policy'
$K INFO replication                        # role, and master_host lines for each master
$K CONFIG GET active-replica
$K CONFIG GET multi-master
$K CONFIG GET storage-provider
$K INFO commandstats | grep -E 'cmdstat_(eval|evalsha|expiremember|pexpirememberat|expirememberat|keydb)'
$K MODULE LIST
$K ACL LIST

If you see	Then
`active-replica yes`	Replicating straight from it into KiviDB does not follow writes (see below). Copy with a tool, or turn active replication off first.
`multi-master yes`	Each master holds part of the writes. Copy from the one replica that has them all, or from each master.
A `storage-provider` other than `none` (FLASH)	The data can be larger than KeyDB's memory. Size KiviDB for the whole dataset: `INFO keyspace` gives the key count, and the disk used by the FLASH directory gives an upper bound.
`cmdstat_expiremember` or `cmdstat_pexpirememberat`	The application sets subkey expiry. Plan for it as described in gotchas.
`cmdstat_eval` or `cmdstat_evalsha`	Use the `lua` or `full` build, or turn Lua on for the KiviDB Cloud database.

Sizing. Give KiviDB at least KeyDB's used_memory plus headroom. With FLASH, measure the dataset instead: load a copy into a test KiviDB and read its used_memory.