Every source connects read-only, gets introspected down to its foreign keys, and rolls back completely if anything fails.
Databases, analytics engines and files land in the same semantic model, so a question written once behaves the same wherever the data sits.
The reference connector. Read-only sessions and full key introspection.
The session is pinned read-only at the server, statements run under a timeout, and introspection reads tables, columns, primary keys and foreign keys. Point it at a replica and production never notices.
Read-only sessions, and date grains MySQL does not ship natively.
MySQL has no native date truncation, so the engine rewrites every grain into an idiom MySQL understands before the query runs. Month, quarter and week all come back correct.
Valid T-SQL, including the parts most generators get wrong.
Paging, date truncation and null ordering are all rewritten into T-SQL the server actually accepts. Connections use a SELECT-only login and a guard that rejects anything else.
Connects with read-only mode on, so the credential cannot write.
The connection sets ClickHouse read-only mode at the session level, which the server enforces itself. Large scans stay fast because the compiler pushes aggregation down rather than pulling rows out.
One question across the catalogs Trino already federates.
Pin a catalog and a schema when you connect. The schema matters: without it, an unqualified table name has nowhere to resolve, and Trino rejects the query before it runs.
Query an analytics file directly, with no server to run.
A DuckDB file behaves like any other source: introspected on connect, modelled, and queried through the same compiler. Useful for an extract you were handed and need answers from today.
Upload a file and query it like a table.
Columns are typed on upload and the file becomes a model like any other. The same questions, the same charts, the same provenance label on the result.
Sheets become tables, on the same query path.
Each sheet is read as a table and joined to the rest of your model. It is the fastest way to bring a finance workbook next to the database it was reconciled against.
Snowflake, BigQuery, Redshift and Databricks connect the same way: a read-only credential, an introspection pass, and the same dedup guarantee.
Warehouse, role and schema pinned at connection time.
Connect with a role that can read and nothing more. Queries run in the warehouse you nominate, so cost stays where your finance team already tracks it.
Service account access, scoped to the datasets you name.
Introspection reads the datasets you grant and nothing outside them. Aggregation is pushed into BigQuery rather than pulled across the wire, which keeps bytes scanned predictable.
A read-only user, a schema, and the usual introspection pass.
Keys and constraints declared in Redshift feed the join graph the compiler reasons over, so dedup planning works the same way it does on Postgres.
SQL warehouse access against the catalogs you allow.
Connect to a SQL warehouse with a token scoped to read. Unity Catalog objects are introspected into models, and the compiler targets the dialect directly.
Connect flow
Connecting is four steps. If any of them fails, nothing is saved and no half-connected source is left behind.
Connect a database
Pick the kind of database you have. You will need its address and a read only login.
PostgreSQL
PostgreSQL database
MySQL
MySQL database
ClickHouse
ClickHouse analytics
SQL Server
SQL Server database
Trino
Trino query engine
DuckDB
Local .duckdb file
Snowflake
Coming soon
BigQuery
Coming soon
Databricks
Coming soon
Connect PostgreSQL
Nothing is saved until the connection works. iDash opens it read only and reads the list of tables.
Connection tested, read only
42 tables and 17 foreign keys read in 1.8s
iDash opens a read-only session under a statement timeout and runs a single probe query. Nothing else happens until that comes back clean.
Tables, columns and types, then the parts that matter most to correctness: primary keys and foreign keys. That is what becomes the join graph.
Host, database, user and password are encrypted field by field with AES-256-GCM before anything is written down. They are decrypted only to open a connection.
A failure at any point rolls the whole attempt back. You either have a working source or you have the error message, never something in between.
Every engine pins its session read-only in its own way, and iDash uses it. A guard rejects anything that is not a single SELECT.
PostgreSQL and MySQL sessions are pinned read-only at the server. ClickHouse connects in read-only mode. SQL Server and Trino run under a login that can only select.
Before anything is sent, a guard rejects multiple statements and anything that is not a SELECT or a WITH. There is no write path to disable because none is built.
Every query runs under a timeout. A question that would sit on your replica for an hour is cancelled instead, and you are told it was.
AES-256-GCM at rest, field by field. Connection details never reach the language model, and never reach the code sandbox.
When a question needs Python, the result set is handed over as a file in a throwaway container. There is nothing in there to connect back with.
Nothing requires production. A read replica gives you the same schema, the same keys and the same answers, with none of the load.
Semantic model
4 models · 3 relationships · derived from foreign keys
Introspection is more than a table list. Primary keys and foreign keys become the join graph the compiler reasons over.
Small things that decide whether a connection works on the first attempt.
Pin both when you connect. With a catalog alone, an unqualified table name has nowhere to resolve and Trino rejects the query outright.
A table with no primary key cannot be deduped, so questions that would inflate it are refused. Declaring keys upstream is the highest value hour you can spend.
CSV and Excel go through the same engine as a database, so a workbook can be joined to a warehouse table without leaving the tool.
T-SQL paging, MySQL date grains and null ordering are rewritten by the engine. You never see a query fail because a function does not exist on your server.
A read-only credential is all it takes. Nothing is written, and nothing is copied out.
Book a demo