Decaf Blog In-depth updates on Decaf software, tooling, and open-source experiments

ingestr v1.0.45 - Catalog Table Names and Braze Segments

3 min read

ingestr v1.0.45 was published on June 24, 2026, with a focused change to destination naming: support for catalog.schema.table names in data loads. The GitHub release page also notes a Braze source change that alters how user_data exports behave when no segments are named.

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

Catalog aware table names

The main operator facing change is support for three part table names in the form catalog.schema.table. That matters for warehouses and lakehouse stacks where catalog selection is not a side concern. A pipeline can now express the catalog, schema, and table in the destination name rather than relying on separate context or adapter defaults.

The same area includes a guard for two part names. The release notes say ingestr should not treat two level destination names as catalog qualified. That is the right distinction. A name like schema.table should remain a schema and table pair, while catalog.schema.table should carry the catalog value explicitly.

This is a small looking parser change with real operational weight. Destination naming sits near permissions, lineage, and table ownership. If a loader reads a two part name as a catalog name by mistake, data can land in the wrong namespace or fail with confusing authorization errors. v1.0.45 narrows that ambiguity.

Multi table destination names get safer

The release also flattens source schema dots in multi-table destination names. The wording is compact, but the intent is useful for anyone loading several source objects through one connector. Source systems often expose names with dots that are meaningful on the source side, but awkward when those names become part of a destination table name.

Flattening those dots keeps generated names less fragile. It reduces the chance that a source schema value is later parsed as another namespace level in the target system. That pairs with the new catalog handling: one path deals with explicit catalog.schema.table values, while the other keeps generated names from accidentally looking like structured namespace input.

There is also an internal refactor in this section. The notes mention catalog aware naming everywhere and removal of a multi-table gating workaround. That sounds like cleanup rather than a new user surface. Still, naming logic is shared enough that centralizing it is practical. It gives future connector work one naming model instead of a pile of local exceptions.

Braze exports all segments by default

For Braze users, user_data now exports all segments when none are specified. This is the other release note that should be reviewed before updating scheduled jobs. A missing segment list no longer implies a narrow or empty export path. It means all segments.

That default can be convenient for initial extraction and broad backfills. It can also increase volume, runtime, and downstream table churn if a job previously depended on the absence of segment filters. Teams using Braze as a source should check pipeline settings before moving this release into a recurring run.

The safest reading is simple: if a Braze job should only export selected segments, name them explicitly. If the job is meant to collect all segment scoped user data, v1.0.45 makes that behavior clearer through the connector default.

Where to get it