How to Define MySQL Ingestion Scope Clearly

July 2026

MySQL scope is easiest to review when the team decides whether the connector should read a named table list or discover every table the database user can see.

Short Answer

Define MySQL ingestion scope with the database in MYSQL_CONNECTION_STRING and a clear decision about tables. The docs say tables is optional and that omitting it lets Skippr discover all readable tables. That means the real source contract is either a named allowlist such as customers,orders or the entire set of tables the MySQL user can read in that database.

A DSN like mysql://skippr@mysql.internal:3306/app answers only where the connector connects. It does not answer whether the source boundary is app.customers plus app.orders or every readable table under app. If the long-term plan is binlog CDC, that same table decision still matters because the connector is following changes for the objects you choose to expose.

Why Teams Struggle with This

MySQL teams often think the connection string is the hard part and leave the table boundary unspecified. That works until someone asks why a table appeared in the warehouse that no one intended to publish, or why CDC was enabled against a broader surface than the team had reviewed.

• A working DSN does not define whether the connector should use explicit tables or discovery.
• Leaving tables empty can be the right choice, but only when the team genuinely wants every readable table in scope.
• A broad MySQL user makes auto-discovery much wider than most teams expect on first launch.
• CDC through binlog replication inherits the same table-boundary decision, so ambiguity early tends to stay ambiguous later.

How Skippr Handles It

Skippr makes this tradeoff visible instead of hiding it. One connector can support an allowlist for a narrow first release or discovery for a broader database handoff, and the config tells reviewers which choice you made.

That is especially helpful for teams moving from batch reads to CDC. The same database can start with a handful of stable tables, then widen intentionally once the downstream models and key assumptions are ready.

• Uses one MySQL connection string plus optional tables selection.
• Lets teams choose between explicit allowlisting and discovery of readable tables.
• Keeps the database boundary visible in the DSN and the table boundary visible in config.
• Extends into binlog CDC without changing the underlying object-level contract.

What the First Useful Version Looks Like

The first useful version is one MySQL database and one short table list. That proves the connector, the user privileges, and the downstream table shapes without turning the first run into a database-wide discovery exercise.

If you deliberately want discovery, review the MySQL user grants before launch and write down that choice. "Whatever this login can read" is a real source boundary and should be treated as one.