redis
Key-value instances via redis:// — keys, TTLs, and a command lab.
redis://:password@host:6379/0Session store, rate limiter, feature flags — Redis sits behind every API Priya ships. She used to ssh in and run redis-cli -a $REDIS_PASSWORD dozens of times a day to check TTLs and flush bad keys during deploys.
Priya saved redis://cache-prod and redis://cache-staging. Keys list with namespaces visible; TTLs show before memory alerts; commands run in a lab tab beside postgres:// without a separate terminal. Local dev uses redis://localhost:6379/0 with no password — same UI, lighter URL.
Cache debugging should take seconds, not a SSH hop and a CLI cheat sheet.

Scheme: redis://
Parameters
redis://:password@host:6379/0
redis://host:6379/0
Step 1
During a deploy Priya scans session:* keys, spots thousands with TTL -1 (no expiry), and traces them to a bad deploy flag. She deletes the namespace subset from the UI and watches memory drop on Pulse.
Database index /0 in the URL path selects the logical Redis DB.
Key listing with pattern filters. TTL and type inspection. redis://:password@host:6379/0 for auth; redis://host:6379/0 for local. Password optional on dev instances.

Step 2
Priya runs HGETALL on a hot hash, then GET on a feature flag key, then a custom Lua-free debug sequence — formatted output, copy button, no ANSI noise.
Command lab sits next to SQL tabs when debugging cross-store bugs.
Redis command execution with structured rendering. Supports authenticated and open local instances. Saved connection names for MCP automation.

Next
Explore the full feature guide: Redis guide