Is selective key export from BGSAVE / PSYNC possible?

[otheng03]

Background

In large Valkey deployments, it is sometimes need to extract a subset of keys based on a custom condition (for example, a hash applied to the key name), while minimizing impact on the running instance.

Using SCAN (or similar keyspace iteration) doesn't seem to be ideal in this case, as it still requires iterating over the entire keyspace and may take a long time or introduce overhead when the number of keys is very large.

Commands like BGSAVE and PSYNC are attractive because they use background processes and allow dumping data efficiently without significantly slowing down Valkey’s main operations. However, they currently dump all keys, which then requires additional post-processing to filter the keys of interest.

Question

I’m looking for a way to extract only a subset of keys that satisfy a specific condition from a snapshot taken at a point in time, ideally without scanning the entire keyspace by SCAN command in the main Valkey process.

For example, consider a scenario like:

• Extract only keys where hash_function(key) == 1000
• The goal is to complete this within a few seconds
• Avoid putting significant CPU or latency pressure on the primary Valkey process

At the moment, the options seem to be:

• Use SCAN and filter client-side → Requires SCAN commands iteration and can be slow at scale.
• Use BGSAVE or PSYNC and post-process the full dump offline → Efficient for the server, but still requires dumping all keys.

My questions are:

• Are there recommended methods or extensions (modules, hooks, etc.) for achieving conditional key extraction more efficiently?
• If this is intentionally unsupported, is the main reason architectural (e.g., design trade-offs)?

Thank you for the reading. Any guidance or confirmation would be greatly appreciated.

[ideacatlab]

Short answer: no — BGSAVE and PSYNC are whole-dataset by design and there's no selective variant in the protocol. BGSAVE forks and serializes the entire keyspace to RDB; PSYNC is the full/partial replication stream of everything. Neither takes a key filter.

For exporting a subset, the supported primitives are SCAN to enumerate and DUMP/RESTORE (or MIGRATE) to move the values. I verified these on a Valkey-compatible instance:

Enumerate the subset without blocking — SCAN is cursor-based and non-blocking (unlike KEYS), and MATCH filters server-side:

valkey-cli --scan --pattern 'user:*'

Export each key's exact serialized value with DUMP, re-create it anywhere with RESTORE:

# round-trip proof (Lua so it's one call):
EVAL "local d=redis.call('DUMP',KEYS[1]); redis.call('RESTORE',KEYS[2],0,d); return redis.call('GET',KEYS[2])" 2 user:1:data user:1:copy
-> "val1"

DUMP gives you the version-tagged serialized blob (same format RDB uses internally), so RESTORE on the target reconstructs the value, TTL and all — this is the per-key equivalent of the RDB export you were reaching for.

Move specific keys atomically to another instance in one shot with MIGRATE ... KEYS k1 k2 … (no intermediate dump file).

On your actual concern — "SCAN still iterates the whole keyspace":

• That's true, but SCAN is non-blocking: it returns in small cursor-batches (COUNT hint), never holds the event loop like KEYS * would, so the impact on the running instance is minimal even on a large dataset. That's the intended tool for exactly this.
• For a hash-of-key-name condition there's no index to avoid the full scan — nothing in Valkey indexes keys by a derived hash, so you iterate all and filter (client-side, or in a Lua SCAN loop to keep it server-side). MATCH only helps if the condition can be expressed as a glob.
• If you control key naming, hash tags ({tag}suffix) or a prefix convention let you target a subset far more cheaply, and even keep related keys co-located on one cluster slot so a MIGRATE can move them together.

So: no selective BGSAVE/PSYNC, but SCAN (non-blocking enumerate) + DUMP/RESTORE or MIGRATE (per-key/selective move) is the real path, and it's the lowest-impact way to pull a subset off a live instance.