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

Zero 1.7 is broadly performance-neutral with Zero 1.6 across client and query-engine workloads, with most benchmarks staying within +/-5%.

The clearest improvements are in replication and storage, especially when Zero is processing changes from Postgres:

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.