Cloudflare D1 vs. Turso: Your Edge MCP Context Store

Cloudflare D1 and Turso (libSQL) are both SQLite-compatible databases built to run at the edge, and open-context supports either one as the backend for its MCP context store. Pick D1 if your infrastructure already lives on Cloudflare and you want one fewer service to run — it needs no client library at all. Pick Turso if the MCP server itself runs somewhere other than Cloudflare, or if you want a database that works the same way whether it's hosted or self-run.

Same SQL family, different transport

Inside open-context, "adding a SQL engine" doesn't mean rewriting how contexts are stored — it means supplying a Dialect and a small driver that implements exec, run, all, and close. D1 and Turso both fall under QUESTION_MARK_DIALECT, the same placeholder style local SQLite uses, because both are SQLite under the hood. That shared contract is why the CLI, the web UI, and every MCP tool (save_context, recall_context, search_contexts, and the rest) behave identically no matter which one is active — what differs between them is entirely how open-context reaches the database over the network, not what comes back.

Cloudflare D1: nothing to install, because it's already HTTP

D1's driver in open-context doesn't use a client library — it posts SQL and parameters straight to Cloudflare's query endpoint (https://api.cloudflare.com/client/v4/accounts/ACCOUNT_ID/d1/database/DATABASE_ID/query) with an API token in the Authorization header. That makes D1 the one remote backend in open-context's lineup with no package to install — pass the token as ?apiToken=… in the connection string, or set CLOUDFLARE_API_TOKEN in the environment and leave it out entirely.

On the pricing side, Cloudflare bills D1 for query and storage costs only — every query returns a count of rows read and rows written, and those counts are what you're charged for, with no separate charge for data transferred out of D1 (Cloudflare D1 docs: Pricing). If you're not running queries, you're not paying for idle compute. That model fits an MCP context store well: most of the traffic is small, bursty reads and writes tied to when Claude actually calls a tool, not a constant background load.

Turso / libSQL: SQLite that isn't tied to one platform

Turso is built on libSQL, an open source fork of SQLite that adds a remote client protocol on top of the same file format and SQL dialect. open-context's libSQL driver connects through @libsql/client, which speaks that protocol over HTTP — the exact same driver code works whether the connection string points at Turso's hosted service (libsql://DATABASE.turso.io?authToken=TOKEN) or a self-hosted sqld server on your own infrastructure, because both sides of that connection speak the same protocol.

libSQL's other headline feature is embedded replicas: an application can keep a local SQLite file that syncs from a remote primary on an interval, serving reads from disk instead of over the network while writes still go to the primary (Turso docs: Embedded Replicas). open-context's driver connects directly to the remote database rather than syncing a local replica, but the option exists in the underlying platform if your own deployment later needs it — nothing about the connection string or the rest of the stack has to change to get there.

Picking between them

Both are squarely SQLite-scale tools, not a substitute for Postgres under heavy concurrent writes — see SQLite or Postgres: Choosing Your MCP Context Store if multiple processes need to write to the same store at once. What D1 and Turso add over local SQLite is reachability: the context store lives somewhere your MCP server can hit over the network, without giving up SQLite's single-file simplicity.

Connecting either one to open-context

Switching backends is always the same shape — one environment variable, one connection string:

# Cloudflare D1 — no package to install
export OPENCONTEXT_DB_URL="d1://ACCOUNT_ID/DATABASE_ID?apiToken=TOKEN"

# Turso — requires: npm i @libsql/client
export OPENCONTEXT_DB_URL="libsql://DATABASE.turso.io?authToken=TOKEN"

Already have contexts saved locally? Test the connection, switch to it, then bring your history along in that order:

opencontext db test "libsql://DATABASE.turso.io?authToken=TOKEN"
opencontext db use "libsql://DATABASE.turso.io?authToken=TOKEN"
opencontext db migrate --to "libsql://DATABASE.turso.io?authToken=TOKEN"

The migration only ever reads from your current store and writes to the new one, so a failed run partway through leaves your original data untouched. The same flow works for D1, or for moving between any two of open-context's 15 supported backends — D1 and Turso included.

FAQ

Does open-context support Cloudflare D1 and Turso for the MCP context store?

Yes. Both are built in as sql-family backends. Point OPENCONTEXT_DB_URL at a d1:// connection string for Cloudflare D1, or a libsql:// connection string for Turso (or a self-hosted sqld server), and the CLI, web UI, and MCP tools behave identically to every other backend.

Do I need to install anything to use D1 with open-context?

No. open-context's D1 driver talks to Cloudflare's REST API directly over fetch, so there's no client package to install — it's the one remote backend with nothing to add to package.json.

What do I need to install to use Turso?

The @libsql/client peer dependency: npm i @libsql/client. It's an optional peer dependency, so it's only required once you actually point OPENCONTEXT_DB_URL at a libsql:// connection string.

Can I use Turso's libSQL driver with a self-hosted database instead of Turso's cloud?

Yes. open-context's libsql driver speaks the standard libSQL wire protocol, so it works identically against Turso's hosted service or a self-hosted sqld server — only the host in the connection string changes.

Can I switch from D1 to Turso, or to another backend, without losing my saved contexts?

Yes. Run opencontext db migrate --to "libsql://DATABASE.turso.io?authToken=TOKEN" and every context and bubble is copied across. The migration only reads from the source store, so a failed run partway through leaves your original data untouched.