DEL-&-UNLINK
DEL removes keys immediately. UNLINK removes them asynchronously. Both are irreversible - unless you have Redimo's Undo feature.
You'll Learn
- DEL vs UNLINK differences
- Bulk deletion patterns
- Why FLUSHDB is dangerous
- How Redimo's Safe Mode protects production
See Your Data, Not Terminal Text
Redimo visualizes every Redis data type beautifully. Edit inline, undo mistakes, stay safe in production.
1. DEL vs UNLINK
DEL removes keys synchronously - Redis blocks until the memory is freed. UNLINK removes keys asynchronously - it returns immediately and frees memory in the background.
For small keys, there's no noticeable difference. But for large keys (big lists, sets, or hashes with thousands of members), DEL can block Redis for hundreds of milliseconds. UNLINK is almost always the safer choice in production.
Syntax
DEL key [key ...] # Synchronous deletion (blocks until complete)
UNLINK key [key ...] # Asynchronous deletion (returns immediately)
# Both return: Number of keys that were deletedUse DEL When
- • Keys are small (strings, small hashes)
- • You need guaranteed immediate deletion
- • You're in a development environment
- • Memory reclamation timing matters
Use UNLINK When
- • Keys might be large
- • You're in production
- • Redis latency matters
- • Deleting many keys at once
2. The CLI Way (Dangerous Mode)
One typo in CLI and your data is gone. Forever. No confirmation dialog, no undo, no second chances:
Basic Deletion
127.0.0.1:6379> DEL user:1001
(integer) 1
127.0.0.1:6379> DEL user:1002 user:1003 user:1004
(integer) 3
127.0.0.1:6379> DEL nonexistent:key
(integer) 0Pattern-Based Deletion (The Dangerous Way)
127.0.0.1:6379> KEYS session:*
1) "session:abc123"
2) "session:def456"
... (imagine 50,000 more sessions)
# Delete all matching keys (requires shell piping)
$ redis-cli KEYS "session:*" | xargs redis-cli DEL
(integer) 50002
# Or the nuclear option:
127.0.0.1:6379> FLUSHDB
OK
# Oops, that was production. All data is gone.
127.0.0.1:6379> FLUSHALL
OK
# Even worse - all databases wiped.The Danger
3. The Redimo Way (Safe Mode)
Redimo's Production Safe Mode shows a red border and "PRODUCTION" badge for production connections. Every deletion requires explicit confirmation. And the Undo feature lets you restore deleted keys within 5 minutes.
What Redimo Does for Deletion Safety:
- ●Visual Environment Indicator: Red border and "PRODUCTION" badge make it impossible to confuse production with development.
- ●Confirmation Dialogs: Every delete action in production requires explicit confirmation showing exactly what will be deleted.
- ●Undo Feature: Deleted keys are cached locally for 5 minutes. One click to restore them. Snapshots include the full value and TTL.
- ●Multi-Select Delete: Select multiple keys with checkboxes, review selection, then delete with one confirmation.
- ●FLUSHDB Protection: Dangerous commands like FLUSHDB are not exposed in the UI. You can't accidentally wipe a database.
CLI Dangers
- • No confirmation prompt
- • No prod/dev visual distinction
- • Deletion is permanent
- • FLUSHDB is one command away
- • No bulk selection preview
Redimo Safety
- • Red border for production
- • Confirmation required
- • Undo within 5 minutes
- • No FLUSHDB in UI
- • Multi-select with preview
4. Bulk Deletion Patterns
Sometimes you need to delete many keys matching a pattern. Here's how to do it safely:
Using SCAN (Production-Safe)
# Never use KEYS in production - it blocks Redis!
# Use SCAN instead for pattern matching
# Bash script for safe bulk delete:
redis-cli --scan --pattern "session:*" | xargs -L 100 redis-cli UNLINK
# Or with SCAN in a loop (pseudocode):
cursor = 0
do {
(cursor, keys) = SCAN cursor MATCH "session:*" COUNT 100
if keys.length > 0:
UNLINK ...keys
} while cursor != 0Lua Script for Atomic Bulk Delete
-- Delete all keys matching pattern atomically
-- WARNING: Still blocks Redis, use for small patterns only
local keys = redis.call('KEYS', ARGV[1])
local deleted = 0
for i, key in ipairs(keys) do
redis.call('UNLINK', key)
deleted = deleted + 1
end
return deleted
-- Call with:
-- EVAL "script" 0 "session:*"Pattern Delete in Redimo
5. Understanding UNLINK
UNLINK is often misunderstood. Here's what actually happens:
Step 1: Key Removed from Keyspace
The key is immediately removed from the keyspace. From this moment, GET and other commands return nil. This is instant.
Step 2: Value Queued for Deletion
The value (list, set, hash, etc.) is moved to a background queue. The main thread continues serving requests.
Step 3: Background Thread Frees Memory
A background thread gradually frees the memory. For a 1GB list, this might take seconds, but Redis remains responsive throughout.
When DEL Blocks
# A list with 10 million elements
LLEN huge:list # Returns 10000000
# DEL blocks until all 10 million elements are freed
DEL huge:list # Might block for 500ms+
# UNLINK returns immediately
UNLINK huge:list # Returns in <1ms, frees in background6. Pro Tips
Check Size Before Deleting
Useful Deletion Commands
# Check key type
TYPE mykey
# Check size based on type
STRLEN string:key # String length
LLEN list:key # List length
SCARD set:key # Set cardinality
HLEN hash:key # Hash field count
ZCARD zset:key # Sorted set cardinality
# Delete with expiration (safer than DEL)
EXPIRE mykey 1 # Expires in 1 second, non-blocking
# Rename to "deleted" namespace, then async clean
RENAME mykey deleted:mykey
# Later: SCAN and UNLINK deleted:* patternRedimo Bonus
Ready to Delete Safely?
Stop risking accidental data loss in CLI.
Download Redimo with Safe Mode and Undo support.