Zero 1.7

Query Correctness and Performance

Installation

Copynpm install @rocicorp/zero@1.7

Overview

Zero 1.7 focuses on query correctness, performance, and operational safety. It improves consistency with different encodings across Postgres, the SQLite replica, and the in-memory JS query engine, as well as performance improvements under load.

Features

• Immutable query result updates: Query result updates now preserve references for unchanged subtrees, improving compatibility with React memoization and Solid reactivity without the earlier eager-expansion regression. (#6093)
• Additional Postgres scalar types: Zero now syncs selected text-represented Postgres scalar types, including network/address types, pg_lsn, and the isn extension family, as string columns. These columns can also participate in Zero primary keys. (#6099)
• Replication lag diagnostics: Added a replication.last_total_lag gauge so operators can distinguish actual replication lag from a stalled lag-report stream. (#6042)

Performance

We benchmarked zero/v1.6.2 against maint/zero/v1.7 (2698272ca) on an M3 Max MacBook Pro with 36 GB RAM, macOS 26.5.1, and Node 22.22.1. The run used 84 comparable zql-benchmarks cases with the same benchmark definitions on both refs.

Overall, the median benchmark was 1% faster. The geometric mean was 3% slower including one severe planned-exists hydration outlier, or 1% faster excluding that single case. 30 of 84 benchmarks improved by at least 5%, while 22 regressed by at least 5%.

Wins were concentrated in Chinook hydration (+38% geomean), manual flip-join cases (+16%), and in-memory IVM hot-path benchmarks (+5%). Regressions were concentrated in planner hydration, transaction-heavy ArrayView updates, and Chinook push workloads.

Fixes

• WebSocket close code 1009 could trap a client in a reconnect loop by repeatedly resending the same oversized message.
• Inspector/analyze-query could show a query plan different from the actual plan generated by the table source.
• Duplicate bundled copies of runtime peer dependencies could break customer-observable behavior such as Pool instanceof checks and React single-instance assumptions.
• Singular and plural queries with the same AST could incorrectly share a client view.
• React and Solid queries with nested relationships using one() vs limit(1) could share a view cache entry and return the wrong nested shape.
• Removing a query could trigger an assertion.
• LIKE/ILIKE matching in the JS query engine used multiline regex behavior instead of dotall behavior, causing mismatches for strings containing newlines. (thanks @sravan27!)
• Range filters (<, <=, >, >=) could use ordering that differed from SQLite/Postgres ordering. (thanks @sravan27!)
• SQLite replica LIKE/ILIKE behavior could diverge from Postgres and the in-memory JS matcher.
• SQLite replica ILIKE did not match non-ASCII case variants such as MÜLLER and müller.
• Litestream-backed deployments could purge change-log entries based on stale claimed backup progress rather than actual backup state. #6123
• Query hydration and pipeline failures now include the query hash, transformation hash, and custom query name when available.

Breaking Changes

None.