ClickHouse has released pgclickhouse v0.11.0 and the chdb extension v0.1.2, adding practical fixes for moving data between ClickHouse and PostgreSQL. The update improves handling of invalid text encodings and adds support for several data types that previously failed or lost useful structure.
ClickHouse Watch analysis
What happened
The releases add a checkencoding option for invalid text bytes. Users can choose to fail on invalid data, remove offending bytes, replace them with the Unicode replacement character under UTF-8, or truncate text at the first invalid byte. The setting is available in pgclickhouse and in chdb’s COPY and CREATE TABLE commands.
The extensions also map ClickHouse interval types to PostgreSQL intervals, with an option to import them as integers. Support for parameterised JSON columns and unflattened Nested columns has been improved; nested values can map to arrays or, with matching definitions, custom composite types. Read ClickHouse’s release overview.
Our top picks
- Choose how to handle invalid text
Set checkencoding to fail, remove, replace or truncate invalid bytes instead of hitting an opaque import error. - Bring interval data across
ClickHouse interval types can now import as PostgreSQL intervals or integers, with query pushdown supported for the described interval example. - Keep more JSON structure usable
Parameterised JSON columns now map to jsonb or json, enabling the demonstrated property sort to push down to ClickHouse. - Choose how nested values map
Unflattened Nested data can use two-dimensional text arrays or suitably defined composite types. - Account for compatibility changes
The deprecated clickhouserawquery() function has been removed, and PostgreSQL 13 support has been dropped.
Why it matters
These changes address the awkward bits of connecting two database systems: encoding errors, types that do not line up neatly, and data structures that used to be rejected or flattened. For teams using these extensions, the new options can make imports more predictable and preserve more of the structure they want to query. The PostgreSQL 13 drop and removed function are the items to check before upgrading.
Our read
This is a meaningful compatibility release, not just a version-number parade. The encoding choices are especially useful because they make the trade-off explicit: replace or remove bad bytes for readable text, or use bytea when preserving the original bytes matters. Check the breaking changes and test representative data before rolling it into production; databases are famously unimpressed by surprises.
What to watch
- Whether future releases expand type mappings or add further compatibility changes.
- How the new encoding options behave with real-world data and non-UTF-8 databases.
- Whether teams affected by the PostgreSQL 13 drop or removed function need migration work.
Discussion spark: When importing invalid text, would you favour replacing bad bytes to keep data readable, or preserving them exactly as binary data?
Sources and evidence
- Source update (30 September 2026, 16:29 UTC)
not affiliated with or endorsed by ClickHouse