Twenty-two capability groups, one self-hostable binary, one licence. Connect a database, ask a question in a visual builder or in SQL, model it, cache it, chart it, schedule it, embed it, audit it — and let a supervised agent layer do the first draft. Below is the whole surface, including the parts that are not built.
Counts taken from the shipping build — version 1.1.695, build 787. Not projections, not a roadmap.
Each group is a working area of the product. Where a deep-dive page exists, it is linked from the card.
Three things a security reviewer will ask about, answered before they have to ask. Two are gaps. One is a deliberate design decision.
Yes. This page is generated from the feature inventory of build 787, version 1.1.695. Where something is not implemented — multi-factor authentication, row-level security, MCP write tools — it is listed in the gaps section above rather than quietly omitted.
40 connection types, compiled through 12 SQL dialect strategies. Native engines are PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, H2, HSQLDB, Derby, DuckDB, Snowflake, Redshift, BigQuery, ClickHouse, Vertica, Trino, Presto, SingleStore, DB2, Sybase and Pervasive. On top of those sit the managed variants with their own type strings — AWS Aurora, RDS, Redshift and Athena; Azure SQL, Synapse, Postgres, MySQL and MariaDB; GCP Cloud SQL, AlloyDB, BigQuery and Spanner.
Wire-compatible engines fold into an existing dialect: CockroachDB, Vertica, Trino, Presto, DuckDB, ClickHouse, Athena and Spanner compile as PostgreSQL, SingleStore as MySQL, HSQLDB and Derby as H2.
No. Agent SQL is read-only and DDL or DML is rejected outright. Every write-side tool stages a proposal with a verbatim payload; the write tools have no path to the real service call at all. A human approves or rejects, and only then does the owning domain service run. The require_approval_for_writes setting defaults to true, and the whole agent layer is off by default per organisation.
None. Qrly ships as one platform with one licence — the agent layer, the OLAP engine, four cache tiers, CDC table sync, the spreadsheet engine, embedding, the public API, the MCP server and the BCBS 239 module are all part of the product. Pricing is on company revenue rather than per seat, so adding users never increases the bill.
Yes. Qrly is self-hostable on Java 25 and Spring Boot with a PostgreSQL application database, and is GraalVM native-image capable. First-run setup is an eight-step wizard that writes nothing until you confirm, with systemd install, start, stop and status built in, pg_dump backups on an operator-editable cron, and a platform console for config, logs, memory and languages.
The AI layer never has to leave the building either — Ollama, LM Studio, Jan.ai, LocalAI, GPT4All, LibreChat, Lobe Chat and Open WebUI are all supported provider types alongside Claude, OpenAI, Azure OpenAI, Gemini and Mistral.
It degrades rather than breaks. Cache failures always fall through to a miss and a live query. Agent tool exceptions are returned to the model as observations so the loop self-corrects instead of dying. Every prompt side-block — connections, recent questions, schema, existing models — degrades to an in-prompt note, so a dead data source never blocks a session from starting. Alert and subscription delivery is best-effort: a failed Slack post is logged, never propagated.
Priced on your revenue, not your seat count. Self-hosted, so your data never leaves your infrastructure.