A spike, not an implementation. The output is an ADR, and the research is deliberately deferred — this issue exists so the reasoning already done is not lost and not redone.
Why it is worth doing
WordPress. It is the single largest category of application a self-hoster wants to run, it needs MySQL, and Burrow currently cannot offer it a database at all. That is a large gap in the building-blocks story for a project whose add-on catalogue exists precisely so a user does not have to hand-roll their own backing services.
The gap is symmetric with the one ADR-0031 closed for Postgres apps, and it is justified on the same terms: an operator running a PHP application on their own cluster has the same problem a Go or Python one already has solved.
What is already established — do not re-derive this
Licensing is not the blocker, and an earlier reading of mine that said otherwise was wrong.
- GPLv2 obligations trigger on distribution, not use. Running software as a service is not distribution — which is why shared hosts have offered MySQL for twenty years without a GPL problem.
- Burrow never ships binaries. An add-on names an image the user's own cluster pulls from a registry; Burrow distributes a reference. That is not conveying, so nothing triggers.
- AGPL is the different case, and the one ADR-0026's permissive bar for
addon install is really about — §13's network clause can create source-provision obligations for whoever operates the service. MySQL and MariaDB are GPLv2, not AGPL. Do not conflate them.
- The one move that would create an obligation is bundling a binary into a shipped artifact. Burrow does not do that for any license.
Two properties look better on MySQL than on Postgres, and both are reasons the spike is worth running rather than assuming parity:
SHOW DATABASES is privilege-filtered by default, where Postgres's catalogue is world-readable. The cross-tenant listing disclosure that had to be closed by hand in the cloud is smaller here by construction.- Thread-per-connection rather than process-per-connection, which is a real density advantage on a shared instance with many tenants.
And one architectural property may be materially better — this is the most interesting thing to verify:
- MySQL replication is binlog-based, can be filtered per database (
replicate-do-db), and carries DDL. If that holds, promotion could replicate a single tenant's database rather than the whole cluster — avoiding both the whole-instance copy and the prune step that burrow-cloud/cloud ADR-0024 §2 has to accept for Postgres, where physical replication is instance-wide and logical replication drops DDL.
What the spike must actually answer
- Which operator, and its license, maturity, backup story and upgrade path. CloudNativePG is Postgres-only (ADR-0066), so this is a second operator to vet and run — the real cost of MySQL support, and it is operational rather than legal.
- Verify the binlog claim. Per-database filtering and DDL propagation are load-bearing above and are asserted from general knowledge, not checked.
- Verify identifier limits. MySQL 8 is believed to cap usernames far shorter than database names (~32 vs 64), which would make a tenant-qualified identifier budget tighter than Postgres's 63 — and tighter budgets make fail-closed composition matter more.
- Does ADR-0031's contract transfer? An instance shared by an environment's apps, with a database and a login role per app. If it does, the user-facing shape is unchanged and MySQL is a backend rather than a new concept.
- Backups. ADR-0032 and ADR-0063 are shaped around
pg_dump and an object-store destination. What is the MySQL equivalent, and does the destination work unchanged?
- Resource footprint at rest, comparable to
LeanPostgresSettings (shared_buffers=64MB, max_connections=30, …). InnoDB's defaults are generous in the same way and presumably tune down similarly, but the number matters for density.
- WordPress specifics — charset and collation defaults, storage engine assumptions, and whether the privileges WP expects are broader than a per-app role should hold.
The architectural question the ADR will have to settle
Is MySQL a second add-on type, or is "relational database" a capability with two backends — the shape ADR-0026 already established for observability, where a capability has adapters and the user asks for the capability rather than the product?
The second is more work and much better if a third engine ever appears. The first is cheaper and is what the add-on catalogue does today. This is the decision, and it should not be made by whoever implements first.
Not now
Filed deliberately unresearched. Nothing here should be treated as a conclusion except the licensing analysis, which is settled.
A spike, not an implementation. The output is an ADR, and the research is deliberately deferred — this issue exists so the reasoning already done is not lost and not redone.
Why it is worth doing
WordPress. It is the single largest category of application a self-hoster wants to run, it needs MySQL, and Burrow currently cannot offer it a database at all. That is a large gap in the building-blocks story for a project whose add-on catalogue exists precisely so a user does not have to hand-roll their own backing services.
The gap is symmetric with the one ADR-0031 closed for Postgres apps, and it is justified on the same terms: an operator running a PHP application on their own cluster has the same problem a Go or Python one already has solved.
What is already established — do not re-derive this
Licensing is not the blocker, and an earlier reading of mine that said otherwise was wrong.
addon installis really about — §13's network clause can create source-provision obligations for whoever operates the service. MySQL and MariaDB are GPLv2, not AGPL. Do not conflate them.Two properties look better on MySQL than on Postgres, and both are reasons the spike is worth running rather than assuming parity:
SHOW DATABASESis privilege-filtered by default, where Postgres's catalogue is world-readable. The cross-tenant listing disclosure that had to be closed by hand in the cloud is smaller here by construction.And one architectural property may be materially better — this is the most interesting thing to verify:
replicate-do-db), and carries DDL. If that holds, promotion could replicate a single tenant's database rather than the whole cluster — avoiding both the whole-instance copy and the prune step thatburrow-cloud/cloudADR-0024 §2 has to accept for Postgres, where physical replication is instance-wide and logical replication drops DDL.What the spike must actually answer
pg_dumpand an object-store destination. What is the MySQL equivalent, and does the destination work unchanged?LeanPostgresSettings(shared_buffers=64MB,max_connections=30, …). InnoDB's defaults are generous in the same way and presumably tune down similarly, but the number matters for density.The architectural question the ADR will have to settle
Is MySQL a second add-on type, or is "relational database" a capability with two backends — the shape ADR-0026 already established for observability, where a capability has adapters and the user asks for the capability rather than the product?
The second is more work and much better if a third engine ever appears. The first is cheaper and is what the add-on catalogue does today. This is the decision, and it should not be made by whoever implements first.
Not now
Filed deliberately unresearched. Nothing here should be treated as a conclusion except the licensing analysis, which is settled.