MySQL vs. SQL Server: Choosing Your Enterprise MCP Store

Pick MySQL for open-context's MCP context store when you want the lowest operational overhead among the enterprise SQL options — it's a single npm i mysql2 away and runs anywhere from a laptop to PlanetScale. Pick SQL Server when Azure SQL, an existing Microsoft licensing agreement, or an IT policy already governs where your data lives — both backends pass the identical save_context/recall_context contract, so the decision comes down to what your infrastructure already runs, not what open-context supports better.

Why "enterprise database" usually means MySQL or SQL Server

Most self-hosted open-context installs start with the default JSON file or move to SQLite, and teams that outgrow a single writer typically reach for Postgres next. MySQL and SQL Server show up for a different reason: they're already running. A company standardized on Microsoft infrastructure has SQL Server or Azure SQL licensed and monitored long before anyone asks Claude to remember project context. A team running WordPress, Laravel, or a decade of PHP tooling already has a MySQL cluster with backups, replicas, and an on-call rotation built around it. In both cases, the practical question isn't "which database is technically best" — Postgres remains the most-used database among professional developers by a wide and growing margin — it's "which one can I point an MCP context store at without asking for a new piece of infrastructure to be approved."

MySQL as an open-context backend

Point OPENCONTEXT_DB_URL at a mysql://user:pass@host:3306/db connection string and install the driver:

npm i mysql2
export OPENCONTEXT_DB_URL="mysql://user:pass@host:3306/opencontext"

Under the hood, open-context's MySQL dialect makes a few deliberate choices rather than accepting server defaults. Every free-text column is declared LONGTEXT instead of TEXT, because MySQL's TEXT type caps at 64KB and, in strict mode, rejects anything longer instead of silently truncating it — a long conversation summary saved as a context would otherwise fail outright. The schema is pinned to utf8mb4_bin collation rather than inheriting the server's default: a latin1-default database (still common on older MySQL installs) can't store emoji or CJK text at all, and MySQL's usual utf8mb4_0900_ai_ci default is both case- and accent-insensitive, which would make a search for "cafe" also match "café" and could collide two different IDs that differ only in case. Case-insensitive search still works — it comes from LOWER() in the query, not from the collation.

This backend also covers anything that speaks the same wire protocol: MariaDB, PlanetScale, Azure Database for MySQL, Google Cloud SQL for MySQL, and Aurora MySQL all work through the identical connection string — append ?ssl=true for managed providers that require an encrypted connection.

SQL Server as an open-context backend

SQL Server and Azure SQL use the same mssql://user:pass@host:1433/db scheme, installed with:

npm i mssql
export OPENCONTEXT_DB_URL="mssql://user:pass@host:1433/opencontext"

The driver behaves differently depending on where it thinks it's connecting. If the hostname ends in .database.windows.net, open-context assumes Azure SQL and turns on certificate verification, since Azure always requires TLS and presents a trusted certificate. Against any other host — a local instance, an on-prem server — it trusts a self-signed certificate by default, which is the normal setup for SQL Server outside Azure, and encryption itself stays on unless you explicitly set ?encrypt=false. Two connection-string details are easy to get wrong: an IP address can't be used as the TLS server name, so SQL Server has to be addressed by hostname; and Azure SQL usernames often contain an @ (like admin@myserver), which needs percent-encoding or the URL parser reads it as the credential separator.

Schema setup also has to account for a race condition that MySQL and Postgres don't hit the same way: SQL Server has no CREATE TABLE IF NOT EXISTS, so open-context checks OBJECT_ID(...) and creates the table only if it's missing. Two processes opening a brand-new database at the same moment can both see nothing and both try to create it — one wins, and the other gets error 2714 (table exists) or 1913 (index exists), which open-context treats as success rather than a failure, since the intent was already satisfied.

Choosing between them

Neither backend is faster or more capable for open-context's purposes — the conformance suite guarantees identical behavior. What actually differs:

• What's already running. If your team already operates one of these, use it. Standing up a new database just for an MCP context store defeats the point of a lightweight tool.
• Licensing and cost. MySQL and MariaDB are free and open source with no per-core licensing to negotiate; SQL Server's licensing is a real cost most teams are already paying for other reasons before they get to open-context.
• Compliance and IT policy. Organizations standardized on Azure or Microsoft's compliance certifications often mandate SQL Server or Azure SQL specifically — that decision is usually made well above the level of an MCP context store.
• Where your team already runs SSL/TLS. SQL Server's encrypt-by-default behavior and Azure auto-detection make it slightly more forgiving of a misconfigured connection string in a cloud environment; MySQL's TLS handling mirrors Postgres's sslmode vocabulary, which is more familiar if you've already configured a Postgres backend.

Switching without losing data

You don't have to get this right on the first try. The same three-command flow that moves data between any two of open-context's 15 backends works here:

# Try the connection first, without committing to it
opencontext db test "mssql://user:pass@host:1433/opencontext"

# Switch the active backend
opencontext db use "mssql://user:pass@host:1433/opencontext"

# Copy everything from the old store into the new one
opencontext db migrate --to "mssql://user:pass@host:1433/opencontext"

The migration only reads from the source store and writes exclusively to the target, so a failed run halfway through leaves your original MySQL data untouched and safe to retry. Bubbles are migrated before the contexts that reference them, and every backend gets its own fresh IDs rather than reusing the source's, exactly as with the SQLite-to-Postgres migration path.

What stays identical no matter which you pick

Both backends run through the same ~50-test conformance suite as every other adapter: identical ordering (createdAt ascending, then id), identical case-insensitive substring search across content, tags, and source, and the same rule that an unset field like bubbleId comes back undefined, never null. save_context, recall_context, and the rest of the MCP tools can't tell which SQL engine is underneath. And because both connection strings carry a password, they're handled the same way as any other backend's credentials — see securing a local MCP server for how open-context redacts them before anything reaches the UI or a log line.

FAQ

Does open-context support both MySQL and SQL Server for the MCP context store?

Yes. Point OPENCONTEXT_DB_URL at a mysql:// or mssql:// connection string and install the matching optional peer dependency — npm i mysql2 for MySQL/MariaDB, npm i mssql for SQL Server or Azure SQL. Both are two of the 15 backends behind the same storage contract, so the CLI, web UI, and MCP tools behave identically either way.

Can I run SQL Server locally, or does it have to be Azure SQL?

Both work. open-context detects Azure SQL by hostname (anything ending in .database.windows.net) and turns on encryption and certificate verification automatically. Against a local or on-prem SQL Server instance it trusts a self-signed certificate by default, and you can add ?encrypt=false to the connection string if the server has no TLS configured at all.

Does open-context work with managed MySQL like PlanetScale, RDS, or Cloud SQL?

Yes. Managed MySQL services all speak the same wire protocol, so the same mysql:// connection string works — append ?ssl=true (or a specific sslmode) for services that require an encrypted connection, which most managed providers do.

Is search behavior different between MySQL and SQL Server?

No. Both pass the same conformance test suite as every other backend, so ordering and case-insensitive substring search return identical results. What differs under the hood is collation: open-context pins MySQL to utf8mb4_bin and SQL Server's key columns to a binary collation, specifically so results match SQLite and Postgres instead of drifting on accents or case.

Can I migrate from MySQL to SQL Server, or the other way around, without losing data?

Yes. opencontext db migrate --to "mssql://user:pass@host:1433/db" (or the mysql:// equivalent) copies every context and bubble across. The source store is only ever read, so a migration that fails partway through leaves your original data untouched and safe to retry.