rqlite 5.10 changes TLS defaults and snapshot storage

A database can keep the same SQL interface while changing what happens during connection setup and recovery. The February 7 release of rqlite 5.10.0 does both. It disables TLS 1.0 and 1.1 by default and changes snapshot and restore paths to avoid temporary files. The release-tagged changelog also records a new startup strategy for disk-backed databases, building them in memory first.

These changes affect different operational costs. TLS defaults determine which clients can negotiate a secure HTTP connection. Snapshot implementation determines how the service turns live database state into recovery material and reconstructs it later. Neither change requires a new application query language, but both can matter when an existing deployment upgrades the executable.

I value rqlite's use of SQLite behind a relatively small distributed service. That makes the boundaries around the engine worth examining. A simple SQL endpoint still depends on sensible transport defaults and a recovery path whose disk and memory work are understood.

The TLS minimum is explicit in the HTTP server

The HTTP service implementation at v5.10.0 initializes its minimum protocol version to TLS 1.2. If the compatibility flag is enabled, it lowers that minimum to TLS 1.0. The resulting configuration also advertises HTTP/2 and HTTP/1.1 as application protocols.

This is a minimum-version setting, not a certificate change. A certificate can still be valid while an old client fails to negotiate the permitted protocol. Conversely, accepting an older TLS version would not solve an unrelated certificate validation error. The implementation treats protocol selection and loading the certificate and key as separate steps.

The executable's flags call the compatibility option tls1011, defaulting to false. Its help text describes support for deprecated TLS 1.0 and 1.1. The program passes that choice to the HTTP service. This gives a deployment an explicit compatibility escape when it still needs an older client, rather than retaining the old protocols silently.

rqlited -http-cert server.crt -http-key server.key node-data

This illustrative invocation supplies certificate paths and uses the new minimum by default. Adding -tls1011 changes that protocol policy. It does not supply a certificate, enable authentication, or define which SQL operations a caller may execute. Those responsibilities remain separate configuration decisions.

The location of the code matters when describing the change. The cited minimum is in the HTTP service. A broad claim that every encrypted connection in the entire system receives the same setting would require examining every other client and transport path. The concrete release behavior is sufficient, callers of the HTTPS endpoint need a compatible protocol.

Snapshots no longer require a scratch database file

The changelog records removal of a temporary file during database snapshotting and during restoration of an in-memory database. It also records a move to the rqlite fork of the Go SQLite driver, explicitly noting that the SQLite C code remains unchanged. The distinction is useful because the release changes the integration around SQLite without attributing the improvement to a new SQL engine version.

The database wrapper in the tag has a Serialize method that obtains a byte slice through the SQLite connection. Failure to obtain that representation returns an error. This gives the snapshot path a database representation in memory without first requiring a temporary file as its interchange format.

The corresponding in-memory deserialization helper reveals another cost. It opens a temporary in-memory database and deserializes the supplied bytes there. It then opens a second in-memory database and copies the first database into it. A source comment explains that the first database still uses memory in Go space and needs that explicit copy.

Removing a scratch file therefore does not mean restoration does no copying. It changes the location and ownership of the intermediate representation. The code still has to turn incoming bytes into a database whose memory lifetime fits the wrapper's use. This is an implementation tradeoff that an operator cannot infer just from a smaller amount of temporary disk activity.

Disk-backed startup has a reconstruction phase

The release also builds disk-backed databases in memory first. The changelog ties that change to startup behavior, and the announcement describes a substantial restart improvement for disk-based nodes. This public material does not establish a universal restart duration, so a deployment should not turn the qualitative improvement into a promised number of seconds.

The reason this belongs with snapshot work is that the local SQLite representation and the replicated history have different roles. Reconstructing a database is work performed around recovery. An on-disk operating mode does not require every intermediate step of that reconstruction to write directly to its final file. This release chooses an in-memory intermediate state for the startup path.

I consider that an appropriate implementation question to expose in release analysis. The final storage mode does not describe peak temporary memory use or every step before the node starts answering requests. The tagged deserialization code gives a concrete example of why those quantities can differ.

Metrics describe the work the release changes

The changelog adds timing for snapshots, restores, and startup, together with total Raft-directory size in store statistics. It also converts Raft statistics to numeric values where possible. Those additions make the affected operations easier to observe without treating the size of the SQLite database as the only measure of a node's storage work.

Shutdown sequencing changes too. The release closes SQLite after shutting down Raft and closes BoltDB when the store closes. These items concern resource lifetime around the replicated store. They belong to the same integration responsibility as serialization, even though they do not change an application's SQL statements.

For an existing deployment, the direct compatibility change is the HTTPS minimum protocol. The snapshot and restore changes alter internal data movement, including temporary storage and in-memory reconstruction. Version 5.10.0 makes those operations more specific and adds measurements for their duration, while retaining SQLite as the local relational engine.