Dbhub vs Redis MCP Server
A side-by-side look at the Dbhub and Redis MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Dbhub for databases work as a local process; choose Redis MCP Server for databases as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Dbhub when
- You need dedicated capabilities in the Databases domain.
- You prefer a local stdio subprocess transport.
- You want tools like
dbhub.toml.
Choose Redis MCP Server when
- You need dedicated capabilities in the Databases domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
REDIS_URL, ALLOW_WRITES, REDIS_COMMAND_TIMEOUT_MS, REDIS_CONNECT_TIMEOUT_MS, REDIS_MAX_KEYS, REDIS_MAX_VALUE_BYTES. - You want tools like
redis_scan, redis_key_info, redis_get.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Databases | Databases |
| Quality signal | 57/100 · Good | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | REDIS_URLALLOW_WRITESREDIS_COMMAND_TIMEOUT_MSREDIS_CONNECT_TIMEOUT_MSREDIS_MAX_KEYSREDIS_MAX_VALUE_BYTES |
| Verified owner | Community listing | Community listing |
| GitHub stars | 3,705 | 2 |
| Directory activity | 1 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 1 | 7 |
| Full listing | View Dbhub | View Redis MCP Server |
Tools & capabilities
Dbhub tools 1
dbhub.toml
Redis MCP Server tools 7
redis_scanEnumerate keys with cursor-based SCAN -- NEVER the O(N) KEYS command, so this is safe to run against a production instance with millions of keys (SCAN yields the event loop between batches). Returns up to REDIS_MAX_KEYS keys (default 1000) matching an optional glob `match` pattern (e.g. `user:*`, `session:??`). When more keys remain, `truncated` is true and `cursor` is non-'0' -- pass that `cursor` back to continue from where you left off. Optionally filter by value `type` (string/list/set/zset/hash/stream). Within one call duplicate keys are removed; across a resumed scan a key may reappear (SCAN's guarantee is no key present for the whole scan is missed, not that none repeats).redis_key_infoInspect a single key without reading its (possibly huge) value: type, TTL (seconds and ms, -1 = no expiry, -2 = key missing), internal encoding (`listpack`, `hashtable`, `intset`, ...), serialized memory footprint in bytes (MEMORY USAGE), and idle time. Use this before `redis_get` on an unfamiliar key to avoid pulling a multi-megabyte value into context, and to spot big keys / missing TTLs.redis_getRead a key's value, dispatching by type so you get the right shape without knowing the type in advance: string -> the value (byte-windowed at REDIS_MAX_VALUE_BYTES, default 256 KiB, with `truncated` + full `length` when capped); hash -> field/value object; list -> array (LRANGE windowed by `limit`); set -> member array; zset -> [member, score] pairs (ZRANGE WITHSCORES, windowed); stream -> recent entries (XREVRANGE, windowed). Collection reads are capped at `limit` (default REDIS_MAX_KEYS) so a million-element list can't blow out context. The size and `truncated` fields come before the payload, so a host that caps tool results below REDIS_MAX_VALUE_BYTES (Yaw MCP: 100,000 bytes by default) cuts payload, not them. Always read-only.redis_commandRun a single Redis command through the safety gate. Read-only commands (GET, HGETALL, LRANGE, TYPE, TTL, INFO, ...) always run. Mutating commands (SET, DEL, EXPIRE, HSET, ...) require ALLOW_WRITES=1. KEYS is blocked (use redis_scan). Arbitrary-execution commands (EVAL, FUNCTION, SCRIPT, MULTI, MONITOR, SHUTDOWN, CLUSTER, ...) are never exposed, even with ALLOW_WRITES=1 -- the gate is a curated allowlist, not a blanket 'anything when writes are on'. Use this for commands without a dedicated tool; prefer the typed tools (redis_get, redis_scan, redis_key_info) where they exist.redis_healthOne-call health snapshot rolled up from INFO + DBSIZE + recent SLOWLOG: server version and mode, uptime, memory used vs maxmemory + eviction policy, connected clients + blocked clients, ops/sec, keyspace hit/miss ratio, total keys per database (and how many lack a TTL), persistence (RDB/AOF) status, replication role, and the most recent slow commands. Use as a connection sanity check and the first stop in 'why is Redis slow / using so much memory?' triage.redis_slowlogRecent entries from the Redis slow log -- commands that took longer than `slowlog-log-slower-than` microseconds (default 10000 = 10ms). Each entry has the command, execution time in microseconds, a unix timestamp, and the client address/name (Redis 4+). The fastest way to find which specific commands are slow. Read-only (SLOWLOG GET); SLOWLOG RESET would need ALLOW_WRITES and is intentionally not exposed here.redis_advisorRolled-up Redis health lint pass -- one call returns four categories of findings, each with a severity and an actionable fix: - big_keys: sampled keys whose memory footprint or element count is large enough to make operations O(N) and risk blocking the event loop on delete/expire. - missing_ttls: share of sampled keys with no expiry -- the classic 'cache fills up and OOMs' setup. - eviction_pressure: used/maxmemory ratio, active evictions, and the dangerous `noeviction` + no-TTL combination that turns a full instance into failed writes. - fork_latency_risk: long last-fork time, large dataset + active persistence, and failed background saves -- the causes of periodic latency spikes and durability gaps. Keys are sampled via SCAN (never KEYS), so it is safe on a large production instance; the big-key / missing-TTL findings are over the SAMPLE, not the whole keyspace.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Dbhub
{
"mcpServers": {
"dbhub": {
"command": "npx",
"args": [
"-y",
"@bytebase/dbhub@latest"
]
}
}
}
Redis MCP Server
{
"mcpServers": {
"redis-mcp-server": {
"command": "npx",
"args": [
"-y",
"@yawlabs/redis-mcp@latest"
],
"env": {
"REDIS_URL": "YOUR_REDIS_URL_HERE",
"ALLOW_WRITES": "YOUR_ALLOW_WRITES_HERE",
"REDIS_COMMAND_TIMEOUT_MS": "YOUR_REDIS_COMMAND_TIMEOUT_MS_HERE",
"REDIS_CONNECT_TIMEOUT_MS": "YOUR_REDIS_CONNECT_TIMEOUT_MS_HERE",
"REDIS_MAX_KEYS": "YOUR_REDIS_MAX_KEYS_HERE",
"REDIS_MAX_VALUE_BYTES": "YOUR_REDIS_MAX_VALUE_BYTES_HERE"
}
}
}
}
Frequently asked questions
Dbhub is categorized under Databases and uses a local stdio subprocess. Redis MCP Server belongs to Databases and uses a local stdio subprocess. Pick Dbhub for databases work and Redis MCP Server for databases.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Dbhub has no declared pricing — check the project's own site. Redis MCP Server has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add dbhub and redis-mcp-server as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Dbhub has a quality signal of 57/100 (Good) with 1 views, 0 installs and 3,705 GitHub stars. Redis MCP Server has 63/100 (Good) with 1 views, 0 installs and 2 GitHub stars.