rqlite 10.2.5 reduces the cost of routine snapshot checks

Routine verification competes with the storage work it is meant to protect. rqlite 10.2.5, released on 29 June 2026, changes the integrity check used after snapshot reaping from SQLite's full check to its quick check. The release makes a specific tradeoff about repeated maintenance cost. It retains a database check while reducing the work that check performs.

This fits what I value about rqlite after a year with it. The project supplies relational storage and replication in a relatively small deployment. Maintenance should remain proportionate too, but a faster check has to be described by the guarantees it retains and omits. Calling both forms an integrity check can conceal that distinction.

Reaping consolidates recoverable state

The snapshot store implementation shows why a database check appears here. Reaping can checkpoint accumulated WAL files into a full snapshot's database, recompute its CRC32 sidecar, remove superseded snapshots, and update metadata. The operation consolidates stored state, rather than merely deleting old directory names.

A check after that work examines the resulting database representation. It belongs to a maintenance path that can run repeatedly as snapshots accumulate. Its cost therefore participates in the continuing operation of the node, even though an application client did not request a validation query.

The store builds a persisted plan for the operation and can resume interrupted reaping. That is a different protection from inspecting the resulting SQLite database. A plan describes how to complete the storage transition after interruption. A database check examines properties of the bytes and structures produced by that transition.

The patch changes a shared verification helper

The implementation change changes VerifyIntegrity() to select the quick mode with a maximum of one reported issue. Its result preserves the distinction between a failed check and an error running the check. The patch's explanation explicitly chooses the faster form for continual automated checking.

This means the change is more precise than removing validation. The operation still asks SQLite to inspect the database, and it can stop after the first discovered problem. What changes is the set of checks SQLite performs before it concludes that no problem was found.

The release changelog identifies this as the post-reap change. It follows recent work verifying snapshot-store integrity before first use. These checks have different timings and purposes, so a successful startup verification should not be confused with checking the output of later consolidation.

Quick checking omits index agreement

SQLite's pragma documentation explains the difference. quick_check omits UNIQUE verification and the check that index contents match table contents. That allows linear running time in the documented row-count model, while integrity_check requires O(N log N). The reduced work is the source of the improvement.

The commands expose their different scopes directly. These examples run through SQLite against a database selected by the caller.

PRAGMA quick_check(1);
PRAGMA integrity_check(1);

The argument limits the number of reported problems. It does not make the full check equivalent to a quick check, because the two commands still examine different properties. A result with no reported issues must be interpreted in terms of the command that produced it.

That distinction matters when diagnosing an index-related problem. A quick result cannot establish agreement between the table and every index if that agreement was outside its scope. The full check remains the relevant tool for that additional question. Its availability complements the cheaper repeated check.

Checksums and SQL structure answer different questions

The snapshot store's CRC32 work records and compares file content checksums. The SQLite check interprets database structures. A checksum comparison can identify disagreement with a recorded byte sequence, while a database check can identify structural inconsistency in the sequence it examines. Neither should be described as a substitute for the other.

This is why the release's tradeoff is defensible without claiming identical coverage. Repeated structural checking can remain in the maintenance path at lower cost. More expensive index consistency work can be requested when that stronger inspection is needed. The policy is understandable only when the omitted work is named.

The change supplies no universal elapsed-time improvement for application queries. Its direct target is verification work associated with snapshot maintenance. The benefit depends on the database and the frequency of that work, so the documented algorithmic difference is the justified performance statement here.

I prefer this explicit division of verification responsibilities. The routine path continues to inspect the consolidated database, and a full check remains available for the additional index questions. Operators reading a verification result need to know which form ran, because a quick success and a full success represent different evidence about the same file.