SearchIndex.drop_keys should use UNLINK instead of DEL

[vishal-bala]

Current behavior

SearchIndex.drop_keys (redisvl/index/index.py:826) issues a synchronous DEL:

def drop_keys(self, keys: str | list[str]) -> int:
    if isinstance(keys, list):
        return self._redis_client.delete(*keys)
    else:
        return self._redis_client.delete(keys)

DEL reclaims memory on the main thread. A single drop of tens of thousands of keys stalls the server proportionally to the freed keyspace. For a SemanticCache use case where scope-targeted invalidation routinely produces sweeps in the 10K–1M+ range (e.g., a policy version rollover in a multi-tenant deployment), this is a customer-visible latency event on every invalidation.

Proposed change

Switch the bulk path to UNLINK, which queues memory reclamation on a background thread:

return self._redis_client.unlink(*keys)

UNLINK returns the same count semantics. It is available on Redis 4+ so there is no minimum-version concern for current RedisVL targets.

If there is a reason to preserve DEL semantics for some callers, expose use_unlink: bool = True and default to True.

Backwards compatibility

UNLINK is a strict superset of DEL for this use case. The only observable difference is that the keys may not be immediately reclaimed from a MEMORY USAGE standpoint — which is the point. Behavior in tests and at the protocol level is identical.

Notes

Surfaced while writing a scoped semantic caching architecture spec. Also relevant to SemanticCache.drop(), which calls drop_keys under the hood when invoked with keys=.

[forhim007]

I prepared a fix for this. The change is minimal:

1. In drop_keys() (sync, line 826): changed self._redis_client.delete() → self._redis_client.unlink()
2. In drop_keys() (async, line 1781): changed await client.delete() → await client.unlink()
3. Updated docstrings accordingly.

UNLINK is available on Redis 4+ and returns the same count semantics as DEL, but reclaims memory on a background thread — much better for large-scale key sweeps in semantic cache invalidation scenarios.

Diff:

--- a/redisvl/index/index.py
+++ b/redisvl/index/index.py
@@ -833,7 +833,7 @@ class SearchIndex:
             int: Count of records deleted from Redis.
         """
         if isinstance(keys, list):
-            return self._redis_client.delete(*keys)
+            return self._redis_client.unlink(*keys)
         else:
-            return self._redis_client.delete(keys)
+            return self._redis_client.unlink(keys)
 
--- a/redisvl/index/index.py  (async version)
@@ -1788,7 +1788,7 @@ class AsyncSearchIndex:
         """
         client = await self._get_client()
         if isinstance(keys, list):
-            return await client.delete(*keys)
+            return await client.unlink(*keys)
         else:
-            return await client.delete(keys)
+            return await client.unlink(keys)

I verified both versions compile correctly with py_compile.

[forhim007]

Hi! I have submitted PR #607 which switches drop_keys from DEL to UNLINK in both sync and async variants. UNLINK is Redis non-blocking alternative to DEL it runs key eviction asynchronously in the background which prevents server stalls when dropping large batches of keys (e.g. during SemanticCache invalidation). Since RedisVL targets Redis Stack 7+ UNLINK is fully supported.