DEL, UNLINK, FlushDB

Imagine your Redis instance is a high-speed warehouse where every key is a pallet of data. As your application grows, you need to remove pallets that are no longer needed—either one at a time or in bulk. Using DEL, UNLINK, and FLUSHDB gives you the control to delete keys individually, perform non-blocking removal, or wipe an entire database. Without these commands, memory leaks and stale data can degrade performance, making your caching layer unreliable. This lesson teaches you how to use each command effectively, so you can maintain a clean and responsive Redis server.

The problem this lesson solves

When Redis holds data that is no longer valid—like expired sessions, outdated cache entries, or temporary results—you need a way to remove it. Accumulating stale keys consumes memory, increases key lookup times, and can trigger eviction policies prematurely. Using the wrong deletion method can block the server (especially with large sets), while ignoring cleanup leads to memory bloat. This lesson solves the practical need to del, unlink, and flushdb with confidence, balancing performance and safety.

Core concept / mental model

Think of Redis as a bookshelf:

• DEL is like taking a book off the shelf and throwing it away immediately — synchronous and blocking. If the book is heavy (e.g., a large list or set), you have to wait until it's fully removed before you can do anything else.
• UNLINK is like marking a book for disposal and having a janitor collect it later — asynchronous and non-blocking. The command returns quickly, and the actual memory reclamation happens in the background.
• FLUSHDB is like emptying the entire bookshelf in one go — synchronous by default, but can also be asynchronous. It removes all keys in the current database.

Key definition: Time complexity matters — DEL is O(N) where N is the number of keys; UNLINK also O(N) but the N is just unlinking overhead; FLUSHDB is O(N) for all keys in the database.

How it works step by step

Step 1: Deleting a single key with DEL

DEL mykey

• DEL removes the key synchronously.
• Returns the number of keys removed (1 or 0 if key doesn't exist).
• If the value is a large data structure (e.g., a list with millions of items), the server blocks until deletion completes.
• Best for small values or when you need immediate confirmation.

Step 2: Non-blocking deletion with UNLINK

UNLINK mykey

• UNLINK is asynchronous — it unlinks the key from the keyspace immediately.
• Returns 1 if the key existed, 0 otherwise.
• The actual memory reclamation happens in a background thread, so the server stays responsive.
• Preferred for large values (e.g., big sorted sets, hashes, or strings).

Step 3: Flushing an entire database with FLUSHDB

FLUSHDB

• Removes all keys in the currently selected database.
• Synchronous by default — blocks until all keys are deleted.
• For asynchronous execution, use FLUSHDB ASYNC. This returns immediately and reclaims memory in the background.
• Use with extreme care in production — there is no undo.

Hands-on walkthrough

Let's simulate a real scenario. Start by adding some test data:

redis-cli

SET session:alice "active"
SET session:bob "expired"
LPUSH messages:queue "msg1" "msg2" "msg3"
SADD tags:active "python" "redis" "tutorial"
HSET user:1 name "Alice" score 100

Now, list all keys:

KEYS *

Expected output:

1) "session:alice"
2) "session:bob"
3) "messages:queue"
4) "tags:active"
5) "user:1"

Example 1: Delete a single key with DEL

DEL session:bob

Output:

(integer) 1

Now verify:

EXISTS session:bob

Output:

(integer) 0

Example 2: Delete multiple keys at once

DEL session:alice messages:queue

Output:

(integer) 2

Example 3: Use UNLINK for a large set

First, create a large list:

LPUSH biglist $(seq 1 1000000)

Now unlink it:

UNLINK biglist

Output:

(integer) 1

Notice the command returns instantly even though the list had a million items.

Example 4: Flush the entire database

FLUSHDB

Output:

OK

Verify all keys are gone:

DBSIZE

Output:

(integer) 0

Pro tip: In Python, you can use redis-py to execute these commands. Example:

import redis

r = redis.Redis(host='localhost', port=6379, decode_responses=True)
r.set('temp', 'value')
print(r.del('temp'))          # Returns 1
print(r.unlink('temp2'))      # Returns 0 if key doesn't exist
r.flushdb()                   # Wipes all keys in current db
print(r.dbsize())             # 0

Compare options / when to choose what

• DEL is fine for single small keys (strings, short lists).
• UNLINK is the safer choice for production code when you delete unknown-sized keys.
• FLUSHDB should be used with ASYNC in production to avoid blocking the server.

Troubleshooting & edge cases

Key doesn't exist

DEL nonexistent

Output: (integer) 0 — no error.

Deleting many keys at once with DEL

If you delete thousands of keys in one DEL command, the server blocks until all are removed. Prefer UNLINK or use a pipeline with DEL spread over time.

Using FLUSHDB on a database with millions of keys

Default synchronous flush can block Redis for seconds or minutes. Always use FLUSHDB ASYNC in production:

FLUSHDB ASYNC

Accidentally flushing the wrong database

Warning: FLUSHDB has no confirmation prompt. Always double-check which database you are connected to with SELECT and CLIENT ID.

Memory not reclaimed immediately after UNLINK

UNLINK only removes the key from the keyspace instantly. The memory is freed by a background thread, so INFO MEMORY may show delayed reduction.

What you learned & what's next

You now understand the core difference between DEL (synchronous, blocking) and UNLINK (asynchronous, non-blocking) for individual key deletion, and FLUSHDB for clearing an entire database. You practiced deleting single keys, multiple keys, large data structures, and flushing databases both synchronously and asynchronously. You also learned when to choose each command based on performance and safety.

Next step: Move on to the next lesson in this track to explore more advanced Redis operations, such as key expiration with EXPIRE, TTL, and PERSIST. Understanding deletion patterns will help you design more efficient caching and data management strategies.