ingestr v1.0.61 - MySQL URI Scheme Updates

ingestr v1.0.61 was published on July 1, 2026 for bruin-data/ingestr, with MySQL source handling as the operational theme. The main change is separate URI scheme handling for Vitess and PlanetScale, backed by a PlanetScale gRPC receive limit above 4 MB, which matters for ETL jobs that read larger result frames or run strict source routing.

The full release notes and downloads are on the GitHub release page.

The most visible change is the split of Vitess and PlanetScale into dedicated URI schemes in the MySQL path. The release notes do not spell out the new scheme strings, so operators should verify connection strings against the project documentation and test runs before changing production jobs.

Why it matters: scheme selection is often how sync jobs choose driver behavior, credential parsing, and error handling. When two backends share too much MySQL surface area, small differences get hidden until a pipeline meets a backend specific edge case.

For platform teams, this is a config review item. Search source configs, job templates, secret names, and deployment manifests for Vitess and PlanetScale sources. The change is narrow, but it touches the first step in every extract job: constructing the source URL.

ingestr v1.0.61 raises the psdbconnect gRPC receive limit above 4 MB. That is the most concrete runtime fix in the release. It targets jobs where a PlanetScale read can return a message larger than the old default and fail before downstream loading gets a chance to run.

This does not mean every query should push larger frames through the connector. Large messages still cost memory and can mask query shape problems. It does mean the connector is less likely to stop on a valid read that crosses the previous boundary.

Data engineers should look at tables with wide rows, JSON columns, high cardinality text fields, or query shapes that return bulky packets. Those are the cases most likely to notice this change during scheduled syncs.

The release also drops a hardcoded source scheme from MySQL fail-fast messages. That sounds small, but it fits the URI split. Once Vitess and PlanetScale have separate schemes, an error that reports the wrong one wastes operator time.

Clear startup errors matter in batch ETL because many jobs fail outside an interactive shell. A bad source string might surface through a scheduled job log or a CI smoke run. The useful message is the one that points to the actual source variant, not to a generic MySQL path.

Operators should treat this as a supportability fix. It does not change data movement by itself, but it reduces the time spent mapping an error back to the wrong URI family.

v1.0.61 is not marked as a prerelease. The notes do not label the URI split as a breaking change, but it is visible enough to deserve a controlled rollout.

Before updating shared runners, test one Vitess job and one PlanetScale job that cover real credentials and a representative table. Check that connection strings resolve to the intended backend, that fail-fast output names the expected source family, and that larger PlanetScale reads no longer stop at the older 4 MB receive limit.

Keep the rollback path simple. This release is small, so the main risk is not a broad behavior change. The risk is stale config that still assumes the old shared scheme model.