PostgreSQL
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.
Connect what you already run.
Every source connects read-only, gets introspected down to its foreign keys, and rolls back completely if anything fails.
Eight sources, one query path.
Databases, analytics engines and files land in the same semantic model, so a question written once behaves the same wherever the data sits.
Databases
MySQL
Time-based queries are automatically formatted for MySQL compatibility, ensuring monthly, quarterly, and weekly totals calculate accurately.
SQL Server
Queries are automatically formatted to meet SQL Server standards, connecting via read-only access to protect your database.
Analytics
ClickHouse
Enforces read-only access at the server level. Analytical queries process directly on the server for fast, responsive performance on large datasets.
Trino
Connect across federated data catalogs easily by selecting your target dataset during setup for seamless query routing.
DuckDB
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.
Files
CSV
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.
Excel
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.
Warehouses on the same path.
Snowflake, BigQuery, Redshift and Databricks connect the same way: a read-only credential, an introspection pass, and the same dedup guarantee.
Snowflake
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.
BigQuery
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.
Redshift
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.
Databricks
Connect securely with a read-only token. Catalog items and tables are mapped automatically for direct, reliable querying.
Connect flow
Test, read, encrypt, or roll back.
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.
- Name
- Production Postgres
- Host
- db.meridian.internal
- Port
- 5432
- Database
- commerce
- User
- idash_readonly
- Password
- ••••••••••••
Credentials are encrypted per field before they are stored
Connection tested, read only
42 tables and 17 foreign keys read in 1.8s
- 01
Test the credential
iDash opens a read-only session under a statement timeout and runs a single probe query. Nothing else happens until that comes back clean.
- 02
Read the schema
Discovers tables, fields, and relationships automatically, mapping how your data connects to ensure accurate reporting.
- 03
Encrypt and store
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.
- 04
Roll back on any failure
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.
Read-only is enforced, not requested.
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.
Enforced by the server
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.
One statement, SELECT only
Requests are strictly limited to read-only queries before execution. Data modification is completely prevented by design.
Statement timeouts
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.
Credentials encrypted per field
AES-256-GCM at rest, field by field. Connection details never reach the language model, and never reach the code sandbox.
The sandbox gets a file, not a database
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.
Point it at a replica
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
customers48.2K
- PKcustomer_iduuid
- FKregion_idint
- first_order_attimestamptz
- channeltext
orders12.8K
- PKorder_iduuid
- FKcustomer_iduuid
- placed_attimestamptz
- net_revenuenumeric
products1.4K
- PKproduct_idint
- categorytext
- unit_costnumeric
order_items43.7K
- PKitem_iduuid
- FKorder_iduuid
- FKproduct_idint
- quantityint
- customers1:Norders
- orders1:Norder_items
- products1:Norder_items
Your schema becomes a model.
Introspection is more than a table list. Primary keys and foreign keys become the join graph the compiler reasons over.
- Relationships are mapped automatically
- Connections between records are identified to understand how data relates, preventing double-counted totals across connected tables.
- Curate it in business language
- Rename net_total to Revenue, hide the columns nobody should see, and define the metrics your team argues about so they resolve the same way every time.
- Reconnect without losing the work
- Schemas change. Reconnecting picks up new tables and columns and shows you what moved, so your curation survives the next migration.
Specifics worth knowing.
Small things that decide whether a connection works on the first attempt.
Trino needs a schema, not just a catalog
Pin both when you connect. With a catalog alone, an unqualified table name has nowhere to resolve and Trino rejects the query outright.
Unique identifiers ensure accuracy
Clearly identifying unique records in your data ensures iDash can always verify and count totals accurately without ambiguity.
Files are first class
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.
Database compatibility handled automatically
Differences across database types and SQL syntax are handled behind the scenes, ensuring smooth, error-free queries across any system.
Connect a replica in minutes.
A read-only credential is all it takes. Nothing is written, and nothing is copied out.
Book a demo