ingestr v1.0.61 - PlanetScale and Vitess URI Handling

ingestr v1.0.61, published on July 1, 2026, is a small release for MySQL style source handling. The main change is practical: PlanetScale reads can now receive larger gRPC messages, while Vitess and PlanetScale connection handling is split into separate URI schemes.

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

PlanetScale reads larger messages

The most visible operator change is in the PlanetScale path through psdbconnect. ingestr now raises the gRPC receive limit above 4MB, which matters when a source response crosses the default message size ceiling.

For ELT jobs, this is not a cosmetic fix. A connector can look healthy during small extracts and then fail as soon as a wider table, a larger row set, or a metadata heavy response appears. That kind of failure is awkward because it depends on source shape and batch size, not only on network reachability.

The release notes do not give a new numeric ceiling, so operators should avoid treating this as a blanket answer to every large extract. It is still a connector limit change, not a general throughput guarantee. The safer reading is that PlanetScale pulls which previously hit the default gRPC receive cap have more room before failing.

This is the change to watch first if an ingestr run against PlanetScale has been sensitive to table width or payload size. It is also the change most likely to remove a failure that appears only after production data volume differs from a test database.

Separate URI handling for Vitess and PlanetScale

The other important change is the split between Vitess and PlanetScale URI schemes. The release notes state that ingestr now treats them as dedicated source schemes instead of keeping the two paths coupled through the same MySQL oriented handling.

That distinction is useful for pipeline configuration. Vitess and PlanetScale are related enough to share history, but they are not the same operational target. A dedicated scheme gives ingestr a cleaner place to attach source specific behavior, validation, and error reporting.

For teams that template connection strings, this is the part of the release that deserves review before rollout. Check any shared secrets, job definitions, environment variables, and generated source URIs that refer to Vitess or PlanetScale. The notes do not describe a full migration guide, so this should be treated as a focused compatibility check rather than a large upgrade project.

There is also a test update for destination schemes covering Vitess and PlanetScale. That is mostly internal coverage, but it is still relevant. URI scheme behavior tends to break quietly when a connector grows new aliases or source types. A test around the split lowers the chance that future connector work folds the two paths back together by accident.

Clearer MySQL source failures

ingestr also drops a hardcoded source scheme from MySQL fail fast messages. That is a small text change with real debugging value.

Fail fast output often becomes the first artifact pasted into an incident note or job log search. If the message names the wrong source scheme, the next person in the chain can spend time checking a connection path that was never in use. Cleaner source naming matters most in shared platforms where MySQL, Vitess, and PlanetScale jobs can sit next to one another with similar credentials and table names.

This change does not alter extraction semantics by itself. It should make failed configuration checks less misleading. For platform operators, that means fewer false trails when validating source URIs or onboarding a new connector template.

The GitHub release page is short, so it is worth reading directly before changing production jobs. The release is not marked as a prerelease in the GitHub metadata.

Upgrade notes

The notes do not call out a breaking change, but the URI scheme split is close enough to configuration that it should be checked deliberately. Any automation that builds Vitess or PlanetScale source strings should be reviewed for assumptions about a shared MySQL scheme.

Run one small extract for each affected source type before promoting the update. That should cover both sides of the release: URI parsing and larger PlanetScale gRPC receive behavior. If the job log has old alerts or runbook text that keys on the prior fail fast wording, update those checks as part of the same pass.

Where to get it