Export MariaDB data, transform it to BigQuery-compatible formats, and load it into BigQuery tables while preserving schema and relationships.
BigQuery offers serverless scaling, lower ops overhead, and native analytics. Migrating frees teams from manual sharding and lets them query terabytes with ANSI SQL.
Extract data, convert schema, load into BigQuery, validate results, and switch applications. Following a repeatable pipeline prevents data loss.
Use mysqldump --tab
for each table to produce .sql
(DDL) and .txt
(TSV) files. This keeps schema and data separate, easing type mapping.
Edit the generated .sql
to match BigQuery types: INT
→ INT64
, DATETIME
→ DATETIME
, DECIMAL
→ NUMERIC
. Save as schema.json
for each table.
Create a dataset, then run bq load --source_format=CSV --skip_leading_rows=0
for every file. Load jobs can run in parallel to cut total time.
Compare SELECT COUNT(*)
results in MariaDB and BigQuery. Small mismatches usually mean unescaped delimiters or wrong null handling.
Update connection strings, rewrite joins using fully qualified table names like project.dataset.Customers
, and retest critical paths.
Chunk exports by primary key range, compress files with gzip
, and load to partitioned tables in BigQuery to keep query costs low.
Schedule nightly exports in MariaDB, push files to Cloud Storage, and trigger a Cloud Function that calls bq load
. This builds an incremental pipeline.
No. Run an initial full export, then incremental dumps during a brief cutover window.
Yes, but you must manually recreate them in BigQuery using Standard SQL.
Most teams move 100 GB in under an hour using parallel gzip uploads and load jobs.