When to Use MySQL as a Source Connector
May 2026
The MySQL source connector is right when MySQL is already the operational store and the team wants a direct extraction path that can later grow into binlog-based CDC.
Short Answer
Use the MySQL source connector when MySQL is already the operational database and you want a direct source-to-destination path instead of relying on exports, CSV dumps, or a second replication product. It is a strong fit when one connection string is enough to reach the database, the source team can expose a stable set of readable tables, and there is a plausible path to binlog CDC later.
A typical example is a transactional app with customers, orders, and subscriptions in MySQL. Skippr can start with table discovery or a short list of named tables, prove the raw extraction shape, and then move toward real-time change capture through binlog replication once the destination keying and downstream expectations are clear.
Why Teams Struggle with This
MySQL is often the obvious source, but teams should separate two decisions: whether table extraction is useful now, and whether they are ready for CDC setup later. The second choice brings binlog prerequisites and operational ownership that are worth deciding deliberately.
- The connector depends on a valid MySQL connection string and basic network reachability to the host and port.
- Auto-discovery is convenient, but a narrow explicit table list is usually better for the first useful version.
- CDC depends on MySQL binlog replication prerequisites, which are separate from basic table reads.
- If the source tables are too operationally volatile or poorly named, the raw extraction can become noisy before it becomes useful.
How Skippr Handles It
Skippr makes MySQL a practical starting point because you can begin with a single connection string and either discovered tables or a hand-picked list. That is enough to make the database an integration boundary without overcommitting on day one.
When the team is ready, the same source can participate in a CDC pipeline into supported warehouse destinations. That gives MySQL a clean adoption path from simple extraction to long-running current-state tables.
- Connects through a standard MySQL connection string.
- Supports table auto-discovery or a named table list.
- Can extend into real-time CDC through MySQL binlog replication.
- Fits direct extraction from operational relational tables into analytical destinations.
What the First Useful Version Looks Like
The first useful version is one database, a handful of high-value tables, and a destination that confirms the source schema is useful before CDC is enabled.
MySQL is a bad fit when the team cannot support binlog requirements for the long-term plan, or when the better integration boundary is a curated topic or file feed rather than the operational database itself.