SynapCores v1.10.0 — Your MySQL app can move in without a rewrite

MySQL's real lock-in was never the wire protocol. It was the dialect — the upsert idiom your ORM emits, the ->> JSON accessors in your queries, the ENUM columns in your schema, the mysqldump sitting in your backups. Move to a new database and all of it breaks at once.

v1.10.0 closes that gap. The MySQL syntax applications actually depend on now runs unchanged, and the constraints you relied on are really enforced — not accepted and silently ignored.

What we made work

-- Upserts, as written
INSERT INTO inventory (sku, qty) VALUES ('A1', 5)
ON DUPLICATE KEY UPDATE qty = qty + 5;

-- JSON accessors and functions
SELECT data->>'$.email' FROM users WHERE JSON_CONTAINS(tags, '"vip"');

-- ENUM columns (enforced as a CHECK under the hood)
CREATE TABLE tickets (id INT PRIMARY KEY, status ENUM('open','closed'));

-- Auto-refreshing timestamps
CREATE TABLE audit (id INT, updated_at TIMESTAMP ON UPDATE CURRENT_TIMESTAMP);

-- Full-text search
CREATE TABLE docs (id INT, body TEXT, FULLTEXT(body));
SELECT id FROM docs WHERE MATCH(body) AGAINST('quick fox');

VARCHAR(n), DATETIME, LONGBLOB, DECIMAL, ENGINE=InnoDB, DEFAULT CHARSET=utf8mb4 — all accepted and mapped to the native table format. And you can point the importer straight at a mysqldump file: oversized INSERTs are chunked automatically, MySQL escape sequences are translated, and LOCK/SET/DELIMITER noise is skipped.

Enforced, not decorative

The subtle trap in "compatibility" is a database that accepts your UNIQUE constraint and then never checks it. v1.10.0 does the real thing: UNIQUE and PRIMARY KEY conflicts are checked against an index-backed probe. A duplicate is rejected. Delete the row and the key frees up, so a re-insert succeeds — exactly as MySQL behaves. Under the hood we also made DELETE and key-changing UPDATE maintain their secondary indexes (and DROP TABLE purge them), so the check never trips on a stale entry.

The part we refused to compromise on

Compatibility features have a way of quietly taxing every write. We made performance a hard release gate: no parity feature is allowed to slow the engine down. Because enforcement is index-backed rather than a full-table scan, it stays sub-linear as tables grow — native inserts show no regression, and constrained inserts carry only single-digit-percent overhead. If a feature had cost more, it wouldn't have shipped.

Why this is the interesting migration

Most "move off MySQL" stories trade one relational database for another. This one is different: your MySQL-shaped app lands with its schema and queries intact, and then gets what MySQL never offered — vector search, durable in-database agents, and AI functions in the same engine, self-hosted on your own box. The dialect you already write, plus the capabilities you were bolting on with three extra services.

Try it

docker pull synapcores/community:v1.10.0-ce

Drop-in from v1.9.1 — no schema migration. Bring a mysqldump, import it, and run your existing queries.