Ridu v0.25.0

Ridu 0.25.0

SQLite now counts filtered lists from its indexes and does less work for each write. On the new
Ridu/PocketBase SQLite benchmark in tests/performance/pocketbase, an anonymous list filtered by an
access rule fell from 5.1 ms to 0.73 ms of server CPU per request with 900 matching posts, and from
14 ms to 1.1 ms with 2,700. Deletes run about twice as fast as in 0.24.0, creates 22% faster and
updates 14% faster. These are measurements from one machine.

This release changes SQLite's index layout and migration planner, so SQLite migration histories and
the databases they migrated must be recreated. PostgreSQL and MongoDB are unchanged.

Changes

• SQLite filters, sorts, distinct values and field indexes share one typed expression: the stored
  value when its JSON type matches the field, otherwise null. An equality or range filter on an
  indexed field, and its total, is answered from the index without reading documents,
  published-only reads included. A scalar in filter is still checked against each candidate
  document.
• A value stored with a different JSON type from its field, such as an object under a text field,
  still never matches a filter. It now sorts with missing values and reads as null among distinct
  values.
• SQLite indexes the columns through which tasks, edit locks and authentication tokens refer to a
  document. Deleting a document no longer scans those tables: with 50,000 retained tasks, a delete
  fell from 9.5 ms to 0.1 ms.
• Each SQLite connection keeps up to 64 compiled statements, of at most 4 KiB of SQL each and 64 KiB
  in all, so a repeated statement skips SQLite's compile step. Larger statements, such as filters
  with long in lists, compile for each call as before.
• SQLite writes skip unique-value and reference work for collections that have neither, and a delete
  no longer repeats cleanup that foreign keys already perform.
• ridu dev brings an existing SQLite development database's indexes up to date before it checks
  the recorded schema, adding the indexes an earlier Ridu did not create. A changed base index or
  table is still reported as drift.

Upgrade

Update the Go module and all Ridu npm packages to 0.25.0 together, regenerate application contracts,
and rebuild the admin and application binary.

• SQLite's migration planner is now 1.4.0. A migration history written by an earlier Ridu is
  rejected as an unsupported planner version, and a SQLite database it migrated fails readiness
  because its index layout changed. Create a new history, for example by moving migrations/ aside
  and running ridu migrate create --name initial, and recreate deployed SQLite databases from it.
  Back up application data and uploads before recreating a database, and rehearse restoration with
  the new schema before cutover.
• SQLite databases that ridu dev synchronizes, which have no migration history, gain the new
  indexes on the next sync.
• PostgreSQL and MongoDB planners, database layouts and migration histories are unchanged.

Ridu requires Go 1.26.9 or newer. Go 1.27.0 and 1.27.1 meet that minimum but still have the
standard-library vulnerabilities described in the 0.20.0 notes, so build and deploy with Go 1.26.9
or a later 1.26 release, or with Go 1.27.2 or later.