0.9.67

ClickHouse and Apache Druid are now supported databases

Two analytical engines land in the same release, and both follow the route Couchbase opened in
0.9.66: they talk to the server over its documented HTTP interface, so neither adds a driver
dependency. package.json is unchanged again — the Docker image, Snap, AppImage, Flatpak, deb/rpm
and the @libredb/studio npm package are exactly the size they were before.

That brings LibreDB Studio to ten engines in one interface: PostgreSQL, MySQL, Oracle, SQL
Server, SQLite, MongoDB, Redis, Couchbase, ClickHouse and Apache Druid.

ClickHouse is the first provider to reach a SQL engine over HTTP through the shared SQL base, so
the explorer, query editor, EXPLAIN tree, monitoring and maintenance surfaces come from the same code
every other SQL provider uses. The HTTP interface has sharp edges that a driver would normally hide,
and the provider handles each one explicitly: a permission denial arrives as HTTP 500 rather than
403, a failure part-way through a result still arrives as 200, writes return an empty body with the
row count in a header, and 64-bit integers are requested as strings so JSON.parse cannot silently
round them.

Apache Druid speaks Druid SQL to either the router on 8888 or a broker on 8082, with no
configuration difference between them. Results are requested in array form because the object form
drops duplicate columns, columns are labelled with their SQL type because the native type
misreports, and EXPLAIN PLAN FOR is rendered as a real tree — the native plan nests, so it fits the
same viewer the other engines use. Three capabilities report false, and each is a genuine engine
limitation rather than something left unimplemented.

Reference: docs/providers/clickhouse.md
and docs/providers/druid.md

Every SQL statement is read with its own dialect's grammar

The editor has to answer three questions about text it did not write: where does this statement end,
what is an identifier, and is it safe to add a row limit. Answering them with one grammar for all
engines was wrong in ways that only show up on specific dialects — a bracket-quoted SQL Server name
containing a semicolon, a MySQL backtick, a dollar-quoted PostgreSQL body, a leading block comment
in front of the real verb.

Statement splitting, identifier quoting, comment handling and automatic row limiting now run through
per-dialect grammars, so the boundary a statement is cut at and the limit appended to it are correct
on all ten engines. This is the layer that decides what gets sent to your database, so it is worth
saying plainly: this release makes it read your SQL the way your database will.

Inline row edits and imports bind their values

Values coming from an inline row edit are now bound as parameters rather than interpolated into the
statement, and the remaining interpolated paths — CSV import and pivot export — quote what they
build. A cell value that contained a quote character previously produced a broken or unintended
statement.

Capability reporting stops overstating

Where a provider cannot do something, the UI now says so instead of offering a control that fails on
use, and the admin maintenance actions are gated on the capability they actually need. Result
channels are carried through both dropped paths, so a query that ends early no longer leaves the
panel showing a stale result.

Azure Marketplace solution template

The repository now builds an Azure Marketplace solution-template package: an ARM template plus
createUiDefinition, validated against arm-ttk in CI, that stands up a VM running LibreDB Studio
behind Caddy with automatic TLS and a self-signed fallback when ACME cannot issue. The package job
reports where the artifact went and what to do with it.

SUSE Ready, and Rancher support in writing

LibreDB Studio is listed in the
SUSE Partner Certification & Solutions Catalog,
which records the platform as SUSE Rancher and the certification as SUSE Ready.
docs/RANCHER.md states the
supported Rancher, RKE2, K3s and Kubernetes versions and the commercial support that covers them.

Helm chart: 0.1.29

Application version only. No template changes — the rendered manifests are identical to 0.1.28.

Full changelog: 0.9.66...0.9.67