questllens-using

questllens-using

Overview

questllens is a read-only lens onto a QuestDB instance: schema, partitions, storage, sample data, execution plans, and live ingestion diagnostics — 18 tools, all read-only. It cannot create a table, alter a parameter, resume a suspended WAL, cancel a query, or write a single row. This shapes every answer: questllens reports what is true of the database now; a human operator is the one who acts on it. This skill orients you and routes you to the right companion skill.

The read-only boundary is enforced by a SQL lexer, not a keyword filter. query accepts only SELECT, WITH, EXPLAIN, SHOW, and TABLES, refuses anything after a ;, and rejects write and admin verbs even inside CTEs and subqueries. Don't try to route around it — a rejection is telling you to change the question, not the phrasing.

Time-series first, relational second

QuestDB is not Postgres with a timestamp column. Four concepts change how you write every query, and getting them wrong is the most common failure mode:

• Designated timestamp — the one column QuestDB partitions and orders by. SAMPLE BY, LATEST ON, and ASOF JOIN are all undefined without it. list_tables shows which tables have one; describe_table names it.
• Partitions — data lives in per-DAY/HOUR/MONTH directories. A query without a time predicate scans all of them. Always bound the time range first, then filter.
• SYMBOL columns — interned strings, cheap to filter on and the intended way to express device/sensor/instrument identity. They have a capacity; exceeding it degrades performance silently. describe_table with with_symbol_stats=true reports distinct counts against capacity.
• WAL — writes land in a write-ahead log and are applied asynchronously. A table can be accepting data while queries see stale rows. "The data isn't there" is often WAL lag, not missing data.

Discovery before guessing

Never write a query against a schema you haven't looked at: