MySQL to Iceberg: land MySQL data in Apache Iceberg

MySQL lands as an Apache Iceberg table in the Raw layer, inside your own S3, under OptimaFlo's BYOC model. Setup is 15 to 20 minutes for the connection and table selection; the schema reflects automatically once a table is chosen. Running MariaDB instead? The same connector handles it, accepting both mysql:// and mariadb:// connection strings; see MariaDB to BigQuery for the MariaDB-specific dialect and driver notes (that page's BigQuery destination is GCP-only, but the MariaDB notes apply on either cloud).

What is actually different about MySQL

The connector mirrors the Postgres one almost exactly (same SQLAlchemy reflection approach, same type mapping to integer/float/string/boolean/timestamp/date, same fail-loud behavior when no table or query is set), with one structural difference: in MySQL, the database is the schema namespace. Postgres has a separate schema concept inside a database; MySQL does not, so table reflection is scoped straight to the database you connect to. It accepts a mysql:// connection string or discrete host, port, database, and credential fields, plus a raw SQL query as the table-less alternative.

Getting from MySQL into Iceberg on AWS

The first pipeline run pulls the target table (or query result) in full and writes it as an Apache Iceberg table in the Raw layer, inside your own AWS account. From there the AI data team builds Clean and Ready models, the same layered process every source goes through, whether it started as a database, a file in cloud storage, or an API response. There is no intermediate stop in a warehouse you did not ask for: Iceberg in your own S3 is the deliverable of this connector, not a checkpoint on the way to one.

Full refresh, not change data capture

There is no binlog tailing here. MySQL supports row-based binary log replication for true CDC, but this connector does not use it: every run is a plain SELECT, either against the whole table or against a query you write yourself. For most reporting workloads, an hourly or daily run against an indexed, append-heavy table (orders, events, logs) is enough. If a table gets frequent in-place updates and you need to track exactly which rows changed since last run, add your own filter (WHERE updated_at > ...) to a custom query; the pipeline does not track a watermark for you automatically today.

If you still want a warehouse on top

Landing in Iceberg does not close off BigQuery or Snowflake, it just stops treating one of them as mandatory. Once Ready-layer tables exist on top of your Iceberg data, the same destination export used by every other connector can push a Gold table to Snowflake, another Postgres, or another MySQL, in append or overwrite mode. BigQuery specifically requires a GCP project to receive it, so it is only reachable if your organization also has a GCP BYOC deployment or a GCP project you are willing to export into.

Honest limits

No CDC, no schema-from-query (a query-based source returns an empty schema rather than guessing one), and no automatic incremental watermarking. If sub-minute freshness is the requirement, this pipeline is not built for that; it is built for the modeling, versioning, and orchestration around a scheduled batch load.