Data integration
MariaDB to BigQuery: sync MariaDB data to BigQuery
Last updated Monday, Aug 31, 2026
How it works
- 1
Point OptimaFlo at your MariaDB server
Hand the Ingestion Engineer a mariadb:// (or mysql://) connection string, or the host, port, database name, and a read-only credential.
- 2
Choose what to sync
MariaDB has no separate schema layer inside a database, so pick a table directly, or hand over a custom SQL query for something that spans more than one table.
- 3
Schema comes back automatically
The connector reflects your table through the same SQLAlchemy path MySQL uses, mapping columns into OptimaFlo's shared type vocabulary.
- 4
First load lands in Raw
The initial pull writes the full result as an Iceberg table in your own cloud, with snapshot history starting on day one.
- 5
Clean, Ready, then BigQuery
The AI data team builds the Clean and Ready layers, then the Gold table exports to your BigQuery project and dataset in append or overwrite mode.
MariaDB is the community fork of MySQL, split off in 2009 after Oracle acquired Sun. It still speaks the MySQL wire protocol, which is why there is no separate mariadb.py connector in OptimaFlo: one connector is registered under both the mysql and mariadb identifiers, and it accepts either a mariadb:// or mysql:// connection string. Table reflection, type mapping, and query execution all run through the same SQLAlchemy path MySQL uses.
Where MariaDB actually differs from MySQL
Since the 10.x fork, MariaDB has added SQL-level features MySQL does not have, extra address types like INET4/INET6, for instance, and drifted from MySQL's window-function and JSON support version by version. None of that touches reflecting an ordinary table: schema inference works the same either way. It only matters if a custom query you write leans on a MariaDB-specific feature; the connector runs whatever SQL you give it and does not translate between dialects.
Landing in BigQuery
From there it is the same pipeline every source goes through: the first run writes the full result as an Iceberg table in your own cloud, the AI data team models Clean and Ready on top, and the Gold table exports to BigQuery in append or overwrite mode. See MySQL to BigQuery for the full walkthrough of the Iceberg landing and the BigQuery export modes; none of that changes for MariaDB.
Sync is full-refresh, not CDC. Each run issues a fresh SELECT against MariaDB, either the whole table or your query, with no predicate pushed down to the source and no binlog consumer involved, so freshness is set by how often the pipeline runs. If you need to isolate changed rows, add your own filter to a custom query; that is on you to write. A query-based source also returns an empty schema rather than a guessed one, the same limit MySQL has.
If sub-minute freshness between MariaDB and BigQuery is the requirement, this pipeline is not built for that; it is built for the modeling, versioning, and orchestration around a scheduled batch load.
Frequently asked questions
Set up by an AI data team, not a config file
Connect this source and see it land in your own cloud.
Now in early beta. One flat plan, no per-query tax. Runs in your cloud. We never store your data.