rqlite adds schema inspection to its interactive client
rqlite 3.11.0 translates familiar schema-inspection commands into queries against sqlite_master. It also introduces a startup wait for applying the initial Raft logs.
A command such as .schema looks like part of using SQLite, but it belongs to an interactive client rather than the SQL language. Sending it unchanged to a database API does not make it an SQL statement. rqlite 3.11.0, released on 12 February, adds client-side handling for schema inspection so that familiar commands work through its replicated database service.
The tagged changelog names support for .tables and .schema through pull request 278. The implementation also handles .indexes. Each command becomes a specific query against sqlite_master, which keeps inspection inside the HTTP query path already used by the CLI.
I value this kind of improvement in a small database tool. Inspecting the schema is a basic part of deciding what query to write next. An operator should be able to discover the stored structure without opening a node's underlying SQLite file or remembering a metadata query before every session.
Dot commands become SQL
The 3.11.0 client source trims each entered line and identifies its first command word. It uppercases that word before dispatch. The new branches recognize .TABLES, .INDEXES and .SCHEMA, then call the existing query function with SQL supplied by the client.
The translations are short enough to show directly.
SELECT name FROM sqlite_master WHERE type="table";
SELECT sql FROM sqlite_master WHERE type="index";
SELECT sql FROM sqlite_master;
These correspond to the three commands in that order. Table inspection returns names. Index inspection returns stored SQL definitions. Schema inspection selects SQL for all entries. The commands therefore provide related but distinct views of the schema instead of returning the same metadata with different formatting.
The implementation is narrower than a claim of complete compatibility with the SQLite shell. It does not parse a table-name argument and add a filter in these branches. Typing a familiar command with additional syntax does not establish that every shell convention has been implemented. The source defines the supported behavior in terms of these fixed queries.
This distinction also explains why the feature does not require a new server endpoint. The server already accepts read queries. The client contributes recognition of an interactive convention and its translation into ordinary SQL. Other HTTP clients can issue the equivalent SQL directly.
Inspection uses the existing remote workflow
The client retains its request machinery for queries and execution. It serializes an entered statement into a JSON array and posts it to the appropriate URL. Its leader-redirection loop remains part of that machinery. Schema inspection therefore uses the remote database selected by the client configuration.
That matters for a replicated database whose local SQLite state belongs to a node. Opening the node's storage directly would introduce a different access path and different assumptions about currency. The CLI's translation avoids requiring that direct file access simply to discover which tables exist.
The source also adds .QUIT alongside the existing quit and exit forms. This is another client convention. It terminates the interactive loop and does not become an SQL command sent to the cluster. The dispatch structure makes the distinction between local interaction and remote database operations explicit.
I prefer these small translations to an interface that only resembles a shell while leaving common commands to fail as SQL. The useful boundary is understandable. The client implements particular conveniences, and the database continues to execute the resulting queries through its established API.
Startup waits for initial log application
The same release introduces a different operational improvement through pull request 268. The store can wait for application of its initial logs. This concerns startup state, independently of whether the user invokes a schema-inspection command.
The released server arguments expose -raftopentimeout, defaulting to 120s. Its help text describes the time allowed for initial Raft logs to be applied, with 0s skipping the wait. That setting is distinct from the heartbeat and Apply timeout options beside it.
These controls describe separate phases of the system. A heartbeat timeout concerns Raft's communication timing. The Apply timeout is passed when submitting commands. The open timeout concerns applying existing history during startup. Giving them separate names avoids making one duration represent every source of waiting in the service.
The release also expands --version output with the commit, branch and platform identifiers GOOS and GOARCH. This supplies context about the executable an operator is inspecting. Together with the startup wait, it improves the operational information around a CLI whose immediate data-facing addition is schema discovery.
The result is a more useful interactive entry point without a new metadata protocol. The client recognizes the requested inspection, emits a query against SQLite's schema catalog and displays the remote result. For the supported dot commands, the convenience belongs to the client and the information still comes from the database.