Skippr Docs

Appearance

How to Manage MySQL Source Credentials in Skippr ​

July 2026

Keep MySQL source credentials safe by loading the DSN from MYSQL_CONNECTION_STRING, keeping table selection separate from the secret, and using a read-focused user instead of an application superuser.

Short Answer ​

Manage MySQL source credentials in Skippr by putting the connection string in MYSQL_CONNECTION_STRING and keeping tables as ordinary config. The docs already separate those concerns: the DSN is the secret because it contains the username and password, while the chosen database and optional table list describe the extraction contract.

That is the practical way to keep a MySQL pipeline readable. Another engineer can see whether Skippr is discovering all readable tables or only a short allowlist, but the password stays in the execution environment instead of in versioned YAML.

Why Teams Struggle with This ​

MySQL credential handling often drifts because teams reuse an application DSN and then keep changing the same high-privilege account for analytics jobs. That creates more risk and more outages than the source connector needs.

  • A literal mysql://user:pass@host:3306/db string in config exposes the password immediately.
  • Using a broad app user makes a simple read connector depend on a credential that may also own writes and schema changes.
  • Switching between auto-discovery and a tables allowlist should be a reviewable config change, not a secret rotation event.
  • If you enable binlog CDC later, the auth and permission story has to support that replication path too.

How Skippr Handles It ​

Skippr works well here because the connector stays narrow. One environment-backed DSN opens the server, and the visible config still shows whether you are reading everything discoverable or only named tables.

That helps teams keep the MySQL secret lifecycle separate from the data-contract lifecycle. You can rotate the DSN without changing table scope, and you can tighten table scope without touching the secret.

  • Uses MYSQL_CONNECTION_STRING for the only secret-bearing field.
  • Keeps optional tables selection visible and easy to review.
  • Supports a clean move from batch reads to binlog CDC when permissions are ready.
  • Fits a dedicated read user instead of a general application credential.

What the First Useful Version Looks Like ​

The first useful version is one MySQL user, one database, and one or two named tables. That proves the connection string, host reachability, and data shape without expanding the blast radius.

If the long-term plan is CDC, decide early whether the same MySQL identity will also support the documented binlog requirements, so you do not create a second secret path later.