mariadb
MariaDB-compatible SQL workbench via mariadb:// connection URLs.
mariadb://user:password@host:3306/databaseHosting providers still ship MariaDB for legacy WordPress and billing stacks — same wire protocol as MySQL, different branding in connection strings. Ops engineer Ren keeps mariadb:// in saved names so staging and production never get confused when a script says connect to Maria Billing.
Ren pasted mariadb://billing:[email protected]:3306/wp_billing, saved Maria Billing Prod, and opened the studio beside a postgres:// analytics tab. The catalog loaded; the grid handled 50k wp_posts rows; Copilot referenced Maria Billing Prod by name in MCP. Ambiguity gone.
Explicit mariadb:// scheme matters when your vault holds both mysql:// and mariadb:// endpoints — Bridge preserves that distinction end to end.

Scheme: mariadb://
Parameters
mariadb://user:password@host:3306/database
Step 1
Ren audits plugin tables before a major WordPress upgrade. The schema tree lists every table; the grid filters postmeta by meta_key; Query lab runs sanity checks on autoload size.
One window, one vault — no separate HeidiSQL session.
MariaDB connections use the mariadb:// scheme explicitly. Default port 3306. Full grid, catalog, and Query lab parity with MySQL. Credentials encrypted locally; saved names flow to nexoxa-mcp and Copilot.

Step 2
Ren's MCP config lists Maria Billing Prod and MySQL Analytics — two engines, two schemes, zero guesswork when Cursor runs a query tool.
The connection card shows the scheme badge so on-call knows which dialect they are in.
Bridge normalizes display but keeps scheme fidelity in the vault. mariadb:// vs mysql:// affects saved name metadata and connection routing, not just cosmetic labels.

Next
Explore the full feature guide: MariaDB guide