Four provider and monitoring defects, a query agent that now carries measured settings for
ten models instead of one, and the Chocolatey channel going live. The provider work is the
reason to upgrade: an engine that could not be added at all, a dashboard that showed nothing
when one of its seven reads was refused, and every MySQL statement travelling a protocol
MySQL itself refuses for some of them.
Every MySQL read went through the prepared protocol
The provider issued every statement through mysql2's execute - the binary prepared
protocol - parameterless statements included. Three engines refuse whole statement classes
there with This command is not supported in the prepared statement protocol yet, and one
of the three is MySQL. CHECK TABLE, the exact text runMaintenance("check") builds, fails
prepared on MySQL 26.7.0 and succeeds as text: one maintenance action was unavailable on the
engine this provider is named for.
One helper now owns all 33 call sites and picks by one fact - a statement with parameters
keeps execute, everything else goes over the text protocol. That the two protocols decode
to the same JavaScript shapes is measured, not assumed: one connection, 23 columns
(TINYINT(1), INT, BIGINT past 2^53, DECIMAL, FLOAT, DOUBLE, DATE, DATETIME, TIMESTAMP, TIME,
YEAR, CHAR, VARCHAR, TEXT, BLOB, BIT(1), BIT(8), JSON, ENUM, SET, NULLs), every value
identical by typeof and by JSON.stringify, every FieldPacket identical in columnType,
flags, characterSet, columnLength and decimals.
Verified in the browser: SingleStore 9.1.1's header badge reads Online instead of Slow, its
fleet card reads 152ms / 4 conn, and its Monitoring dashboard renders a version, an uptime,
Connections 7/100000 and Tables 2 / 2 indexes where the whole panel used to fail.
One refused read cost the whole monitoring dashboard
getMonitoringData composed its seven reads with Promise.all, so a single rejection threw
away every panel that had already answered. Measured on StarRocks 3.3, which has no
information_schema.PROCESSLIST: the provider answered overview, performance, slow queries,
tables, indexes and storage, and the user saw nothing but the engine's sentence about the one
read that failed.
The four core reads are optional now, and each rejection is recorded with the engine's own
sentence, which the panel renders in place of its content. It still throws when all four core
reads reject, because that is a dead connection rather than a partial answer. Repairing the
aggregate also exposed two panels that had been publishing a fabricated zero.
ScyllaDB could not be added at all, and an Oracle LOB failed the whole query
Five monitoring reads query Cassandra's system_views virtual tables. ScyllaDB has no such
keyspace, and the provider degraded a monitoring read on a permission denial and on nothing
else - deliberately, so that a typo in our own CQL could not hide behind an empty panel. The
result was that a ScyllaDB connection could not be created in the first place.
Oracle's driver returns a Lob instance for LOB columns by default, and that shape does not
survive serialization, so any query touching one failed in full rather than returning its
rows. Six defects in total, each measured against a live server before and after and
re-measured in a browser against a production build.
The query agent carries measured settings for ten models
Ten models were run across every agent surface and the settings that worked are now data
rather than a single default compiled in. An operator can supply their own layer for a model
we have never measured - on Kubernetes through the chart's agent.modelTuning, which mounts
a JSON document; a document that is missing, unreadable or off-schema is ignored and the
shipped settings stand, so it cannot break a working agent.
A run now records what drove it: which model, and where that model's settings came from.
And a plan run no longer scores as answered while handing back prose glued to its SQL.
Chocolatey is live
choco install libredb-studio resolves from the community repository - the first submission
was approved on 2026-08-24 - and every release now packs and pushes automatically. Because
the community repository human-reviews each new version before approval, a pushed version is
queued rather than instantly installable; the release run reports the push outcome and the
feed's status for that version in its job summary, and a push that the moderation queue
refuses is a warning rather than a failed release.
Helm chart: 0.1.49
No packaged template changes. The chart tracks app release 0.13.4 and its default image tag
follows; 0.1.48's optional model-tuning ConfigMap and read-only mount are unchanged.
Full changelog: 0.13.3...0.13.4