denis256 notes and projects

ingestr v1.0.48 was published on June 26, 2026, with a focused update for database ingestion paths. The main change is Vitess and PlanetScale support in the MySQL source, backed by tests for detection and OLAP row cap behavior. The release also tightens PostgreSQL CDC slot handling after a successful batch run, and it is not marked as a prerelease.

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

Vitess and PlanetScale support lands in MySQL

The user facing change in v1.0.48 is Vitess and PlanetScale support in the ingestr MySQL source. That matters for teams using MySQL compatible storage where the wire protocol looks familiar, but the operational model is not the same as a single MySQL server.

PlanetScale sits on Vitess, so source detection and query behavior have to handle that shape instead of assuming a plain MySQL deployment. The release notes call out direct support for Vitess and PlanetScale, which means operators can treat these systems as first class MySQL source targets in this release rather than as an awkward edge case.

The practical value is simple. If ingestion jobs already depend on the MySQL source, this release reduces special casing for Vitess backed databases. There is no migration guide in the notes, so the safe read is that this is an additive source capability, not a breaking change.

OLAP row cap behavior gets coverage

The changelog also includes a Vitess integration test for OLAP row cap bypass. That sounds narrow, but it is exactly the kind of narrow test that prevents annoying production surprises.

Vitess can apply limits and behavior that differ by workload mode. A row cap bypass path for OLAP work needs to be tested against the Vitess path, not only against a generic MySQL mock. This release adds that coverage, so the PlanetScale and Vitess support is not just a connector label change.

For operators, the key point is confidence around larger analytical reads. If a job is meant to scan more rows for an OLAP style workload, the connector should not fail because it treated Vitess like the wrong class of MySQL source. The release notes do not claim a broad performance change, so do not read this as a speed release. It is a correctness and coverage release.

PostgreSQL CDC confirms successful batches

The other operational fix is in PostgreSQL CDC. ingestr now confirms the replication slot on a successful batch run.

That behavior matters because replication slots are part of the contract between a CDC reader and PostgreSQL. If a batch has succeeded, the source should be able to move the confirmed position forward. When that confirmation does not happen at the right time, operators can see repeated work, growing retained WAL, or noisy recovery behavior depending on how the surrounding job is managed.

The release note is specific: confirmation happens on a successful batch run. It does not say that failed batches are acknowledged, and that distinction is important. A failed batch should not advance state as if the data was safely handled. This is the boring kind of CDC fix that tends to save time later.

Test cleanup around Vitess detection

There is also test cleanup around Vitess detection. The changelog mentions asserting mock expectations in the Vitess detection test, plus a lint change.

That is mostly internal, but it supports the same theme as the rest of the release. New source behavior needs tests that fail when the detection path is not exercised. The lint item is not user visible, and there is no reason to dress it up as more than housekeeping.

Where to get it

• Release page: GitHub release page
• Project repo: project repo
• Tag: v1.0.48