Ask your database a question,
get an answer you can check
Connect Postgres, BigQuery, Snowflake or ClickHouse, define your measures once, and let anyone on the team ask in plain language. Every answer arrives with a chart, a table, and the SQL it ran.
From a connection string to a board
The modelling is a first pass you edit, not a project you schedule.
Connect a database
Point it at Postgres, BigQuery, Snowflake, ClickHouse or any of the fourteen supported engines. Credentials are encrypted at rest, and a connection can be marked read-only so nothing but SELECT ever reaches it.
Curate the model
The schema is introspected and a first pass of cubes, joins and measures is generated. Hide what nobody should query, rename what only its author understood, and add the measures your business actually reports on.
Ask, then pin
Ask questions in plain language, check the SQL behind the answer, and pin the ones worth keeping to a board your team opens every morning.
Connect a database
Point it at Postgres, BigQuery, Snowflake, ClickHouse or any of the fourteen supported engines. Credentials are encrypted at rest, and a connection can be marked read-only so nothing but SELECT ever reaches it.
Curate the model
The schema is introspected and a first pass of cubes, joins and measures is generated. Hide what nobody should query, rename what only its author understood, and add the measures your business actually reports on.
Ask, then pin
Ask questions in plain language, check the SQL behind the answer, and pin the ones worth keeping to a board your team opens every morning.
Self-serve analytics that does not invent numbers
A semantic layer under the questions, so the answers agree with each other.
Ask in plain language
Type the question the way you would ask a colleague. The answer comes back as a table and the chart that fits the shape of the result — plus the query it ran, so anyone can check the working.
A semantic model, not a guess
Measures, dimensions and joins are defined once and compiled into every query. Revenue means the same thing in every answer, and a question the model cannot express does not quietly become a hallucinated join.
Verified questions stay verified
Approve the SQL behind a question once and it is reused the next time someone asks it, instead of being re-derived from scratch and coming back subtly different.
Boards, built from answers
Pin any answer to a board. Boards carry multiple tabs, shared filters and a date window that stays relative — a board saved as "last 7 days" still means last 7 days next month.
SQL Lab for the rest
Some questions are faster to type than to explain. Write the SQL yourself, run it against the same connection, and promote it to a verified pair when it earns its place.
Share numbers, not credentials
A shared board shows the figures without handing over the database behind them. Access is granted per data source, and a viewer gets a board rather than a query console.
What it connects to, and what you get
Everything the modelling layer, the boards and the SQL console actually support.
Databases and warehouses
- PostgreSQL, MySQL, SQL Server, Oracle
- BigQuery, Snowflake, Redshift, Databricks
- ClickHouse, DuckDB, SQLite
- Athena, Trino / Presto, Spark SQL
The semantic layer
- Cubes generated from your schema, then curated
- Measures and computed dimensions you define
- Joins suggested from keys, confirmed by you
- Derived cubes for the shapes SQL alone gets ugly at
- Business context and vocabulary the model reads
Boards and charts
- Multiple tabs inside one board
- Relative date windows that stay relative
- Board-level filters that lift out of every tile
- Charts picked from the shape of the result
- Share by link, with the data source withheld
For people who write SQL
- SQL Lab against the same connection
- Verified question and SQL pairs
- Table scope — what the model may and may not see
- Row limits enforced on every query
- Schema refresh when the warehouse changes
Available to your agents
- Agents can query the same semantic model
- Answers land in chat, the inbox, or a scheduled report
- MCP endpoint for external clients
- Per-run logging of question, query and cost
Control
- Access granted per data source
- Read-only connections
- Credentials encrypted at rest, never returned to the browser
- Board sharing that does not carry the connection
Why teams stop screenshotting dashboards
What changes when the numbers answer for themselves.
Every question about the numbers goes into the analyst queue and comes back next week
Anyone asks in plain language and gets the answer, with the SQL attached
An LLM pointed at raw tables, confidently joining the wrong two columns
Queries compiled from a semantic model you defined and can audit
"Revenue" means one thing in the finance sheet and another in the ops dashboard
One definition of each measure, used by every answer and every board
A dashboard saved as "last 7 days" that quietly means one week in March forever
Relative date windows that stay relative
Sharing a number means sharing a database credential
Boards shared without the connection behind them
Questions about asking your data
What data teams check before pointing this at production.
PostgreSQL, MySQL, SQL Server, Oracle, ClickHouse, DuckDB, SQLite, BigQuery, Snowflake, Redshift, Databricks, Athena, Trino / Presto and Spark SQL. A connection can be marked read-only so nothing but SELECT ever reaches it, and credentials are encrypted at rest and never sent back to the browser.
A model guessing at raw table names will happily join the wrong two columns and hand you a confident, wrong number. Here the questions run against a semantic model: you define the measures, the dimensions and the joins once, and every answer is compiled from those definitions. "Revenue" means the same thing in every chart, and a question the model cannot express against the model does not silently become a made-up query.
No. The schema is introspected on connect and a first pass of cubes, joins and measures is generated for you. You then curate — hide the tables nobody should query, rename the columns whose names only make sense to the person who created them, and add the measures your business actually reports on.
Yes. SQL Lab is there for the questions that are faster to type than to explain, and a query you trust can be saved as a verified pair so the same question asked in plain language later reuses the SQL you approved rather than being re-derived.
Every answer comes back with a table and a chart the platform picked for the shape of the result, and any of them can be pinned to a board. Boards hold multiple tabs, carry their own filters and date windows, and can be shared with people who should see the numbers without being given access to the database behind them.
Access is granted per data source, and a shared board does not carry the connection with it — a viewer sees the board, not a query console. Read-only connections, row limits on every query, and per-run logging of what was asked and what it cost apply throughout.
Connect a database and ask it something
Free to start, no credit card, and read-only connections so the first question cannot break anything.