rqlite brings SQLite 3.38 into its query engine

A distributed database's SQL capabilities depend on the engine executing its statements. rqlite 7.3.2, released on March 1, upgrades its SQLite dependency to 3.38.0. This is the substantive change behind the release's maintenance version number. The surrounding rqlite service keeps its role, while the local SQL engine gains the operations introduced in SQLite's February release.

The tagged changelog also records an end-to-end encrypted-node test and a change to JSON output escaping. Those concern transport verification and response representation. The engine upgrade has a different consequence for application authors because it changes what a query can ask SQLite to compute.

I value rqlite's use of an established embedded SQL engine beneath its distributed coordination. It makes an upstream improvement available without requiring the project to invent a separate relational implementation. JSON extraction is a concrete example of that relationship, with type rules that remain relevant even when the caller reaches the engine through a network service.

The engine distinguishes JSON text from SQL values

SQLite 3.38.0's release notes introduce -> and ->> and make JSON support part of the default build. The operators both select document contents, but differ in how they return the selected value. That difference matters when another SQL expression consumes the result.

The SQLite release tests exercise strings, numbers, arrays, objects, and missing members. A string selected with -> retains its JSON representation, including quotation marks. The SQL-returning ->> operator returns the ordinary string value. An extracted integer similarly has a numeric SQL type through ->>.

SELECT '{"quantity":12}' -> 'quantity';
-- JSON text representing 12

SELECT typeof('{"quantity":12}' ->> 'quantity');
-- integer

SELECT '{"name":"widget"}' ->> 'name';
-- SQL text widget

These examples describe engine evaluation. They do not specify the outer JSON envelope used by a rqlite HTTP response. An application receiving a result has to distinguish the SQL value in a column from the network representation carrying that column. An engine can return text that itself contains a serialized JSON value.

Null conversion affects the meaning of a result

The tests show another distinction with a document member containing JSON null. Using the JSON-returning operator produces text representing null. Its SQL-returning counterpart produces SQL NULL. An absent member also produces SQL NULL, so the SQL-returning form collapses two document states into one result.

A query asking whether a field was supplied may need that distinction. A query intentionally treating missing and explicitly null values alike may prefer the conversion. The engine does not know which meaning the application assigns to the document. Choosing the extraction expression makes part of that policy explicit.

Objects and arrays remain serialized text when returned through ->>, because the implementation does not provide an ordinary SQL array or object value for them. The tests inspect the JSON subtype as well as the displayed result. Two expressions can therefore print similar contents while carry different information for subsequent JSON construction.

This is especially relevant when a query builds another JSON object. The same test suite distinguishes a string containing array syntax from a value explicitly produced as JSON. Passing ordinary text does not automatically make its contents a nested array. The query author needs to preserve the intended representation at that boundary.

The implementation remains text-based. The JSON source in 3.38.0 says that it stores JSON as text and has no JSONB representation. Moving support into the default build changes availability, while the underlying document encoding remains separate. A service bundling that engine inherits those representation rules along with the new operators.

An engine upgrade has a defined scope

The upgrade does not mean rqlite has become a separate document database. It means its SQLite dependency can evaluate the JSON expressions provided by that engine version. Applications still choose which attributes belong in relational columns and which belong in documents. The new operators make document access shorter while retaining the need to understand the selected value's type.

The SQLite release also adds query-planner work, including Bloom filtering for large analytic queries. That is an internal execution change alongside the SQL additions. A dependency upgrade can consequently affect both the statements accepted and the programs generated for existing statements. Those are different parts of the engine contract even when they arrive together.

For rqlite's release, the tagged changelog identifies the dependency version precisely. That makes it possible to connect a query capability to the engine actually bundled with the service. Reading only the rqlite version's patch number would not reveal the added SQL operations.

I regard that traceability as a strength of this maintenance release. A caller can use the new JSON expressions with an understanding of their upstream semantics, while rqlite continues supplying the distributed service around execution. The important application decision is which representation each query should return, particularly where missing fields, JSON null, and ordinary SQL values meet.