CloudQuery PostgreSQL v8.15.0 - Lakebase Destination Support

CloudQuery PostgreSQL destination v8.15.0 was published on June 19, 2026, with Databricks Lakebase support as the main operator visible change. For teams using CloudQuery as an ELT bridge into Postgres compatible stores, this release makes Lakebase a supported destination path rather than an ad hoc target.

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

The release adds support for Databricks Lakebase as a destination in the CloudQuery PostgreSQL destination plugin, tracked in #22944 and commit 016717c. That is the change that matters here. Lakebase speaks to the same operational problem as a normal PostgreSQL sink: take structured records from CloudQuery sources and land them in a queryable store where platform and data teams can run downstream checks.

The release notes do not describe new flags or migration commands. Treat the change as a compatibility addition for the destination plugin, not as a rewrite of the sync path. The practical read is simple: if your pipeline already models CloudQuery output around PostgreSQL tables, Lakebase can now sit in that destination role.

This is relevant for teams that keep security inventory, cloud asset data, or service metadata in relational form. It keeps the data engineering concern near the sink contract: schema creation, inserts, updates, and error handling around a PostgreSQL style target.

The tag name is explicit: plugins-destination-postgresql-v8.15.0. This is not a broad CloudQuery core release. It is scoped to the PostgreSQL destination plugin, which matters when you decide how much testing to run before upgrade.

For platform operators, that suggests a focused validation pass. Run one representative sync into an existing PostgreSQL target, then one into Lakebase if that is the new target. Check table creation, data type mapping, write throughput, retry behavior, and any constraints your downstream jobs expect. The release notes do not claim behavior changes outside the destination plugin.

That boundary also helps with rollback planning. You can pin this destination plugin tag in the part of the pipeline that owns sink behavior, while leaving unrelated CloudQuery plugins out of the change window.

The only bug fix listed is a dependency update to github.com/cloudquery/plugin-sdk/v4 at v4.95.3, tracked in #22946 and commit b9aac1f. The notes do not attach a specific user visible bug to the bump. That makes it dependency maintenance from an operator perspective.

Dependency maintenance is still worth noticing in ETL systems. Destination plugins sit on the path where schema operations, batching, retries, and telemetry meet the target database. An SDK change can alter shared plugin behavior even when the release note looks small, so it belongs in the smoke test set.

There is no breaking change section in the release notes. There is also no mention of a schema migration step. The reasonable upgrade posture is a normal destination plugin rollout with logs watched around first sync and first resync.

Use the GitHub release page as the source for the release artifact and the exact notes.