How MySQL Source Authentication Works in Skippr
June 2026
MySQL source authentication in Skippr starts with one connection string, but a production auth model still has to match whether the source is batch-only or expected to grow into binlog CDC.
Short Answer
MySQL source authentication in Skippr uses a single MySQL connection string such as mysql://user:pass@host:3306/db, and the docs recommend keeping that DSN in MYSQL_CONNECTION_STRING instead of writing secrets directly into config. For straightforward batch reads, the auth model is exactly that simple: a user who can connect to the right database and read the tables Skippr will ingest.
Where teams get tripped up is assuming the same minimal login tells the whole story forever. The source docs are clear that batch reads and CDC are separate concerns. A DSN that works for a first table extract is not automatically the full production auth model if you later expect binlog-based CDC semantics.
Why Teams Struggle with This
MySQL authentication feels familiar, so people often stop thinking once the DSN parses. The better reading of the docs is that authentication and intent belong together: the user, database, network access, selected tables, and any later CDC expectations all shape whether the source definition is actually complete.
- The connector authenticates with one MySQL connection string, which should be supplied through
${MYSQL_CONNECTION_STRING}. - For batch reads, the MySQL user still needs read access to the tables the source will ingest.
- The source docs point to separate CDC requirements for binlog replication, so a batch-only login may not be the long-term auth model.
- Missing host reachability or the wrong database name can look like credential trouble even when the username and password are valid.
How Skippr Handles It
Skippr keeps the auth surface intentionally small. One DSN is enough to describe the connection identity, database, and secret, which is often the cleanest way to run MySQL ingestion in local development, CI, or a scheduled runtime.
That small surface also makes it easier to evolve safely. You can validate a read-focused source user first, then revisit the auth and privilege model only if the business case really needs CDC instead of forcing replication-level permissions into every early evaluation.
- Connection-string authentication through
${MYSQL_CONNECTION_STRING}. - A clear batch-read starting point centered on readable tables in one database.
- Documentation that separates basic source auth from CDC-specific binlog prerequisites.
- A compact source contract that is easy to test from the same machine that will run Skippr.
What the First Useful Version Looks Like
The first useful version is one MySQL DSN and one or two tables with known contents. That proves the connector can authenticate and read the right database before you widen scope.
If CDC is on the roadmap, plan a second review of the user privileges instead of quietly assuming the batch credentials already cover it. The cleaner auth model is the one matched to the real ingestion behavior.
