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

CloudQuery PostgreSQL Destination v8.15.0 - Lakebase Destination Support

3 min read

CloudQuery plugins-destination-postgresql-v8.15.0 was published on June 19, 2026, with Databricks Lakebase support added to the PostgreSQL destination plugin. For data engineering teams that already move CloudQuery tables into PostgreSQL targets, this release matters because it widens the destination surface without turning the release into a broad behavior change.

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

Lakebase support is the main change

Databricks Lakebase support is the only feature item in this release. The release notes point to #22944 and commit 016717c.

The practical reading is simple: the PostgreSQL destination plugin can now target Lakebase as a destination path. The notes do not list new CLI flags, config keys, or migration commands, so operators should treat this as a connector capability addition and validate it through their existing CloudQuery sync setup.

That is useful when Lakebase is part of the analytic storage plan but CloudQuery remains the extraction layer. It lets the destination choice move closer to Databricks while the upstream source tables and schema mapping stay in CloudQuery. The release notes do not claim any change to extraction behavior, table discovery, or source plugins.

Keep the blast radius small

Because the release is scoped to the PostgreSQL destination plugin, the main operator task is compatibility testing rather than pipeline redesign. Run a representative sync into Lakebase, then compare table creation, type mapping, inserts, and updates against the same job that targets a regular PostgreSQL endpoint.

The release notes do not mention batch size changes, retry behavior, transaction handling, or schema migration semantics. That absence is important. If your sync depends on destination behavior at the edge of PostgreSQL compatibility, test those paths directly instead of assuming Lakebase behaves exactly like every other target.

This is also a good place to check observability. Confirm row counts, failed write logs, and destination side error messages before moving scheduled jobs. The release is not marked as a prerelease, but a new destination target still deserves a staged rollout.

The SDK bump is maintenance

The bug fix section contains one dependency update: github.com/cloudquery/plugin-sdk/v4 moves to v4.95.3. The notes cite #22946 and commit b9aac1f.

Release notes do not describe a user visible PostgreSQL behavior fix from that bump. Read it as plugin SDK maintenance unless your own plugin estate is pinned to SDK versions and you need to align local builds or tests.

That still matters to platform teams. Destination plugins sit in the write path, where dependency changes can affect error wrapping, logging, schema operations, or transport behavior even when the release text is terse. The right response is not panic. It is a small regression run that covers the tables and data types your jobs actually write.

What this release does not say

Short release notes are useful when they are honest. This one does not claim throughput gains, new source support, changes to scheduler behavior, or a new migration story. It also does not list breaking changes.

That keeps the upgrade decision narrow. If you need Lakebase as a CloudQuery destination, the GitHub release page is the release to inspect. If you do not need Lakebase, the SDK bump may still be worth picking up during normal maintenance, but there is no release note evidence here for changing your rollout priority.

For teams running many CloudQuery jobs, the useful question is whether Lakebase belongs in the destination matrix. If yes, add it to the same checks you use for PostgreSQL destinations: schema creation, write behavior, null handling, large text fields, timestamp values, and failure recovery. The notes give enough signal to start that test, not enough to skip it.

Where to get it