MySQL general availability: criteria for full support

[58bits]

@byline/db-mysql ships in 4.8.0 as preliminary, not as fully supported MySQL support. This issue tracks what has to be true before that qualifier comes off, so the status has a visible close condition rather than being an open-ended caveat.

Where it already stands

Both halves of the MySQL implementation are now complete.

The storage layer passes the entire shared @byline/db-conformance behavioural suite — the same suite @byline/db-postgres runs — with identical results across document storage, versioning, patches, workflow, populate, and admin auth.

Search is no longer a gap. @byline/search-mysql shipped in 4.9.0 and passes the full @byline/search-conformance aggregate suite against a live database, the same suite @byline/search-postgres passes, with its own independent numbered migration stream.

What remains is tooling, not implementation. A MySQL installation works; it just has to be wired by hand.

Criteria

• A MySQL search provider — @byline/search-mysql: InnoDB FULLTEXT SearchProvider driver #52, shipped in 4.9.0. validateSearchConfig no longer forces MySQL installations onto a no-op provider; register mysqlSearch({ pool, defaultLocale }) and apply migrate(pool) from @byline/search-mysql. See Search on MySQL in the adapter README.
• CI coverage — CI: add a non-UTC TZ leg for the db adapter conformance suites #55, narrowed and closed. The MySQL service stays pinned to mysql:8.0: that is the documented engine floor, and pinning it is what actually exercises the floor rather than a version comfortably above it. A version matrix on every run was descoped to keep CI times short — 9.x is covered by local development (mysql/docker-compose.yml runs mysql:latest) and can be run manually when a MySQL release lands. The timezone gap was closed, because it was the one that could hide a real regression: a non-UTC leg re-runs both adapter conformance suites under TZ=Asia/Kathmandu (UTC+5:45, so it also catches whole-hour-offset assumptions).
• CLI adapter selection — byline init scaffolds a Postgres installation only. Adding MySQL means hand-editing byline/server.config.ts: swapping the adapter and admin-store imports, swapping postgresSearch for mysqlSearch, and pointing the env at a MySQL connection string. The installer should offer the choice and emit correct wiring for either. This is now the only blocker.

On the CLI criterion

Worth recording what this involves, since it is more than a prompt. packages/cli has no MySQL awareness at all today — src/lib/pg-url.ts, src/phases/db.ts, src/phases/db-init.ts, src/manifest/deps.ts, and src/manifest/env.ts are all Postgres-shaped, and src/phases/db-init.ts applies storage migrations by running drizzle's node-postgres migrator over src/templates/migrations/.

That last point is the structural one: neither @byline/db-postgres nor @byline/db-mysql publishes its storage migrations. Both set files: ["dist"], neither exports a migrate() entry point, and the .sql files live under src/database/migrations/ where tsc does not copy them. The CLI carries its own bundled copy of the Postgres migrations instead. So "CLI adapter selection" implies deciding how MySQL's three storage migrations reach an installed project — bundling a second copy in the CLI, or giving the adapters a published migration surface the way both search packages already do (files: ["dist", "migrations"] plus an embedded-SQL migrate(pool) that stays bundler-safe).

Not blocking, but worth resolving alongside

• A MySQL storage-benchmark target — MySQL storage-benchmark target — measure view materialisation performance #53, still open and still wanted. The design spec flags view materialisation (the ROW_NUMBER() window inside a derived table, used by both current-version views) as a question to answer before GA. Postgres has a benchmark sweep; MySQL has no counterpart.
• MariaDB — MariaDB support for @byline/db-mysql (on demand only) #54, deferred and on demand. The boot check rejects it explicitly today.

Closing this

When the CLI criterion is met: drop the status banner from the adapter README, update the note in Core Document Storage, and say so in a release changeset.

Design and plan: specs/2026-07-24-db-mysql-adapter-design.md