September 11, 2026 · 7 min read

Redis or MongoDB for an MCP Context Store: How to Choose

Q: Does open-context require Redis or MongoDB?

No. The default store is a local JSON file at ~/.opencontext/contexts.json and needs no setup at all. Redis and MongoDB are optional backends you point open-context at by setting OPENCONTEXT_DB_URL, useful once you already run one of them or need a shared store.

Q: Can I switch from the default JSON store to Redis or MongoDB without losing data?

Yes. Run opencontext db migrate --to " " and it copies every context and bubble from your current store into the new one. It only reads the source store, so the existing data is never modified or deleted.

Q: Does open-context support Valkey, Upstash, or Amazon ElastiCache?

Yes. Any of them work through the same redis:// or rediss:// connection string, since they all speak the Redis wire protocol. open-context also accepts a valkey:// alias and rewrites it automatically.

Pick Redis if you already run Redis, Valkey, Upstash, or ElastiCache and want fast, simple reads on a store that stays modest in size. Pick MongoDB if you want a managed, document-native store with indexes and room to grow, and don't mind a 16MB cap per saved context. Both plug into open-context's MCP context store through the same connection string, behave identically from Claude's point of view, and pass the exact same test suite.

Key takeaways

open-context's BYODB layer treats Redis and MongoDB as one "document/KV" family behind a shared adapter, so save_context, recall_context, and search_contexts behave identically no matter which one you pick.
Redis stores each collection — contexts, bubbles — as a single hash and reads it with one HGETALL call, which Redis's own docs mark O(N) over the hash size.
MongoDB stores each context as its own document keyed by _id, with indexes on bubbleId and createdAt — but every document is capped at 16 megabytes by the BSON format.
Search and tag filtering run in memory on both backends, because neither has a portable case-insensitive substring query — a large store searches faster on a SQL backend instead.
Switching later costs one command: opencontext db migrate --to "<connection-string>" copies everything across without touching the source.

Two backends, one shared contract

open-context's context store isn't tied to a single database. It's an async adapter interface with three implementation families behind it: SQL (Postgres, MySQL, SQLite, and others), a bespoke SurrealDB adapter, and "document/KV" — the family Redis and MongoDB both belong to, alongside Firestore and DynamoDB. Adding a new document backend means writing six small methods — connect, close, ping, get, put, remove, list — and a shared adapter implements save, recall, search, tagging, and bubble cascades on top, once. That's why the choice between Redis and MongoDB isn't a choice between two different tools with different behavior — it's a choice between two ways of storing the same JSON documents.

Redis: one hash per collection

Redis gets two hashes total, keyed opencontext:contexts and opencontext:bubbles. Every context or bubble is a field in that hash, stored as a JSON string. A read is a single HGET, a write is a single HSET, and listing a whole collection is one HGETALL call that returns every field in the hash at once.

That last part is also Redis's limit here. HGETALL is documented as O(N) over the size of the hash, and it's the call every list, search, and recall goes through — there's no way to page through a Redis hash and get an atomic snapshot the way HGETALL does. For a personal store or a small team, that's irrelevant; for a hash with tens of thousands of fields, it means every search briefly loads the whole thing into memory and blocks the server for the call.

Connection strings are the standard redis://host:6379 or rediss://host:6379 for TLS, and they work unmodified against Upstash, Amazon ElastiCache, and self-hosted Valkey — open-context also accepts a valkey:// alias and rewrites it before handing the URL to the client. The client retries a first connection a few times and then gives up fast if Redis was never reachable, but once it has connected successfully, it keeps reconnecting indefinitely — the right behavior for an MCP server or HTTP server that needs to ride out a Redis restart or failover without going down itself.

MongoDB: one document per context

MongoDB takes the opposite shape: every context and every bubble is its own document, keyed by _id set to the same id open-context uses everywhere else. A lookup by id is a primary-key hit, not a scan, and open-context creates indexes on bubbleId and createdAt the first time it connects — useful once bubble filtering or ordering matters on a larger store.

The tradeoff is MongoDB's own document size cap. BSON documents cannot exceed 16 megabytes, so a context entry that approaches that size — someone pasting an enormous log dump into save_context, for instance — will fail to save on MongoDB where it would succeed everywhere else open-context can store it. In practice this rarely matters for short notes and memory summaries, but it's worth knowing before you pick MongoDB for a workload that saves large blobs of text.

Connection strings are mongodb://user:pass@host:27017/db for a self-hosted instance, or mongodb+srv://... for MongoDB Atlas — open-context preserves the +srv scheme exactly, since dropping it would turn an Atlas SRV lookup into a direct connection to a host that doesn't answer. Azure Cosmos DB's MongoDB API works through the same driver too, since it speaks the same wire protocol.

Search is identical either way — and slower than SQL either way

recall_context and search_contexts behave the same on Redis and MongoDB: both backends read every entry in the contexts collection and filter case-insensitively in memory, because neither one has a portable case-insensitive substring predicate. Mongo has a regex operator; Redis has none at all; Firestore and DynamoDB fall into the same bucket. Rather than give each backend its own slightly different search behavior, open-context evaluates the filter in one place, so results are byte-identical to what a SQL backend returns for the same query — the whole point of the ~50-test conformance suite every backend has to pass.

The cost is real on a large store: a SQL backend pushes the filter down into the database and only moves matching rows. If your context store grows past a size where full in-memory scans start to show up as latency, that's the point to look at Postgres or SQLite instead — see SQLite or Postgres: Choosing Your MCP Context Store for when concurrent writers or store size actually justify the move.

How to actually choose

Situation	Pick
You already run Redis, Valkey, Upstash, or ElastiCache for something else	Redis
You already run MongoDB or MongoDB Atlas	MongoDB
Want managed hosting with secondary indexes on a document store	MongoDB
Contexts might approach 16MB (large pasted transcripts, logs)	Redis, or a SQL backend
Store will grow into the millions of entries with frequent search	Postgres / SQLite
Not running any database yet	Stick with the default JSON file

The simplest rule holds for both: if you already run one, use it. Standing up a new database purely to back an MCP memory store rarely pays for itself against the zero-setup default JSON file at ~/.opencontext/contexts.json.

Switching backends

The store resolves in a fixed order, and OPENCONTEXT_DB_URL always wins:

opencontext db status                                  # see what's active now
opencontext db use "redis://localhost:6379"            # switch to Redis
opencontext db use "mongodb://localhost:27017/opencontext"  # or switch to Mongo
opencontext db migrate --to "<new-connection-string>"   # copy contexts and bubbles across

db migrate only ever reads the source store, so it can't damage the store you already have — run it, verify the target looks right, then switch OPENCONTEXT_DB_URL over. Each driver is an optional peer dependency, so install the one you need: npm i redis for Redis and Redis-protocol services, or npm i mongodb for MongoDB and Atlas.

See every supported backend, including Redis and MongoDB, in the README.

Get started with open-context →

FAQ

Does open-context require Redis or MongoDB?

No. The default store is a local JSON file at ~/.opencontext/contexts.json and needs no setup at all. Redis and MongoDB are optional backends you point open-context at by setting OPENCONTEXT_DB_URL, useful once you already run one of them or need a shared store.

Can I switch from the default JSON store to Redis or MongoDB without losing data?

Yes. Run opencontext db migrate --to "<connection-string>" and it copies every context and bubble from your current store into the new one. It only reads the source store, so the existing data is never modified or deleted.

Is search slower on Redis or MongoDB than on Postgres?

On a large store, yes. Postgres pushes the search filter down into the database; Redis and MongoDB have no portable case-insensitive substring query, so open-context reads the whole contexts collection into memory and filters there. Results are identical across every backend, just not equally fast at scale.

Does open-context support Valkey, Upstash, or Amazon ElastiCache?

Yes. Any of them work through the same redis:// or rediss:// connection string, since they all speak the Redis wire protocol. open-context also accepts a valkey:// alias and rewrites it automatically.

What happens if a saved context is larger than MongoDB's 16MB document limit?

The save fails, because MongoDB rejects any BSON document over 16 megabytes. Redis, the JSON file, and every SQL backend open-context supports have no equivalent per-entry size cap.