Redis vs DBHub (Postgres)
Redis MCP and the DBHub Postgres MCP are both official servers, but they sit on opposite sides of the database world. Redis's server speaks the rich Redis data-structure vocabulary directly: an agent can set and get strings, manipulate hashes, push and pop lists, add to sets and sorted sets, append to and read streams, store and search vectors, and work with JSON — each Redis type has its own tools. It treats Redis as the fast in-memory key-value and data-structure store it is. DBHub, from Bytebase, is a universal relational gateway pointed at PostgreSQL: the agent gets execute_sql and search_objects, exploring schema and running SQL over a Postgres database through a DSN, typically with a read-only safety mode available. So one server exposes data-structure operations against an in-memory store; the other exposes general SQL against a durable relational engine. Here is a balanced look at how they differ for agent work.
How they compare
| Dimension | Redis | DBHub (Postgres) |
|---|---|---|
| Data model | Key-value and data structures: strings, hashes, lists, sets, sorted sets, streams, JSON, and vector entries — Redis's native types. | Relational tables and SQL: a Postgres database explored and queried through standard SQL over a DSN. |
| Interface style | Type-specific tools (set, get, hset, lpush, zadd, xadd, set_vector_in_hash, and many more) mirroring Redis commands. | Two general tools — execute_sql to run queries and search_objects to explore schema — covering any relational operation via SQL. |
| Typical role | Fast cache, session store, queue, leaderboard, or vector index — low-latency operations on in-memory structures. | Durable system of record: transactional relational data the agent reads and queries with the full power of SQL. |
| Setup | Runs over stdio via uvx (redis-mcp-server) with a redis:// URL to your instance. | Runs over stdio via npx (@bytebase/dbhub) with a postgres:// DSN; the same gateway can target other engines too. |
| Best-fit task | Letting an agent work with caches, queues, streams, leaderboards, or Redis-backed vector search using native data-structure operations. | Letting an agent explore schema and run arbitrary SQL against a relational Postgres system of record. |
Verdict
These are complements more than rivals, so choose by the job. Reach for the Redis server when the agent needs to touch fast, in-memory data structures — caches, sessions, queues, streams, sorted-set leaderboards, or vector search — using tools that map onto Redis commands directly. Reach for DBHub Postgres when the agent needs general SQL over a durable relational database: schema exploration and arbitrary queries through one execute_sql tool, often with a read-only safety mode. Many stacks run both: Postgres as the system of record and Redis as the speed layer. If you must pick one server, let the data model decide — data structures and low latency point to Redis; relational tables and SQL point to DBHub Postgres.
FAQ
- Why does the Redis server have so many tools while DBHub has only two?
- Redis exposes one tool per data-structure operation (strings, hashes, lists, sets, sorted sets, streams, JSON, vectors), so the count is high. DBHub abstracts all relational work behind execute_sql and search_objects, since SQL itself is the general interface to a Postgres database.
- Can Redis replace Postgres here?
- Usually not — they solve different problems. Redis is an in-memory store for fast data structures, caching, and queues; Postgres is a durable relational system of record queried with SQL. Many architectures use both servers, with Redis as a speed layer in front of Postgres.