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 a targeted performance win. It makes several important hot paths faster in real applications: keeping up with busy Postgres databases, running relationship-heavy queries, and analyzing queries.

Postgres Change Processing

Zero 1.7 makes the replication path noticeably faster: change streams process about 1.7x-1.9x faster than 1.6. Initial sync is also modestly faster.

Flipped Joins

Flipped joins help relationship and existence queries avoid work that used to scale poorly as result sets grew. In Zero 1.7, direct flipped-join batching is roughly 3x faster, and large merge-shaped ZQL queries improve dramatically, reaching 109x faster at 10,000 rows.

Query Analysis and Logging

Zero 1.7 also removes overhead from analyze-query and the inspector. Query analysis tools that record many vended rows avoid the old O(N²) cost, making Debug.rowVended up to 3,241x faster. Logger context allocation is also 1.32x-1.59x faster, reducing overhead in logging-heavy code paths.

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.