ingestr v1.1.9 was published on July 23, 2026. Its main operator change stages truncate plus insert loads before any destination table is touched, putting a clearer boundary between load preparation and destination writes.
The full release notes and downloads are on the GitHub release page.
Destination writes move behind a staging boundary ¶
The clearest operational change is the new order for truncate plus insert loads. ingestr now stages the load before touching the destination table. Material for the load is prepared first, while the destination remains outside that preparation phase.
That boundary matters when preparation fails. A destination table no longer needs to be involved while ingestr assembles the staged load. The change narrows the part of the run in which destination state is exposed to work that has not finished preparing.
The release notes do not say whether the final truncate and insert operations use one transaction. They also do not document the storage used for staging or how abandoned staged data is cleaned up. Operators should not treat staged as a promise of atomic replacement. A useful upgrade test is to force a failure after staging and another during the destination write, then inspect both the destination and any temporary artifacts.
Staging can exchange destination risk for temporary storage and cleanup work. Watch free space, object counts, permissions, and cleanup behavior during the first production runs. Those checks are especially relevant for large replacement loads, where a second copy of the incoming data may be operationally significant.
MySQL CDC hardening targets correctness ¶
The second data integrity change hardens MySQL CDC safety guarantees. The changelog does not identify the affected invariant, code path, or failure case. It also makes no throughput claim and names no new configuration flag.
Treat this as a correctness update rather than a performance update. Before promoting the version, exercise inserts, updates, deletes, and process restarts against a representative MySQL source. Compare destination records with the source instead of relying only on a successful process exit.
No compatibility change or migration step is stated. That does not establish exactly once delivery, nor does it define behavior for every restart boundary. The practical reading is narrow: MySQL CDC received safety work, but the public notes are not detailed enough to replace a pipeline level validation.
Typeform joins the source set ¶
ingestr v1.1.9 also adds a Typeform source. This creates a direct source option for teams moving Typeform data into an existing ingestion path. The release notes confirm the source addition, but do not list supported resources, authentication requirements, pagination behavior, or schema rules.
The first extraction should therefore be treated as contract discovery. Start with a bounded data set, inspect field types and null handling, and record how response changes appear at the destination. Test any required historical load separately from the regular schedule because the notes do not define backfill behavior.
The changelog includes a merge entry for the same Typeform work. That is not a second operator feature. Apart from Typeform, MySQL CDC hardening, and staged truncate plus insert loads, this release documents no other user visible changes.