Connect a warehouse

A dashboard can only refresh if there is something to re-query. Connecting a warehouse is what turns a one-time dashboard into one that re-runs its own SQL on a schedule with no AI in the loop.

Dashies calls these data sources in the app. The wire format, the API fields, and the error strings call the same thing a connection, so both words appear on these pages.

Pick your engine

The Refreshing dashboard column says the same thing as the note, per engine.

Engine	Refreshing dashboard	What it connects to	Page
PostgreSQL	yes	Postgres or a Postgres-compatible warehouse.	Postgres
BigQuery	yes	Google BigQuery, via a service account.	BigQuery
Snowflake	yes	Snowflake, via key-pair authentication.	Snowflake
Amazon Redshift	not yet	Amazon Redshift, via the Data API.	Redshift
Databricks	yes	Databricks SQL Warehouse, via the Statement Execution API.	Databricks
SQL Server	yes	Microsoft SQL Server or Azure SQL.	SQL Server
Oracle Database	yes	Oracle Database, self-managed or Autonomous.	Oracle Database

A warehouse dashboard is served

A dashboard that reads a warehouse keeps its data with Dashies rather than inside the published file. Each refresh runs your SQL, writes the result to Dashies' own storage, and the page asks for what it needs when a reader opens it. Every engine the roster admits is on that path; there is no second shape to choose between.

The in-file materializations - cube, lattice, hybrid and rows, which ship the numbers inside the page - are not available on a warehouse you connect, because nothing already inside a file can be filtered per reader. A publish that asks for one on your own warehouse connection is refused, and the refusal says so.

There is one exception, and it is about a plan rather than about a connection: the shared Dashies sample data connection is a warehouse too, and on a free plan a dashboard built on it carries its numbers inside the page instead. On a trial or a paid plan the same dashboard keeps its data with Dashies like any other warehouse dashboard. Nothing about who can read the sample changes either way.

One consequence to design for: the refresh is asynchronous. A newly published dashboard reads "Updating" until the first refresh lands, rather than carrying numbers from the moment you published.

What to have ready

Pick your engine below. The tab you choose is remembered across this whole site, so every other page with engine tabs will open on the same one.

Where to add one

You add a data source in the Dashies web app, never through your AI tool. Credentials are entered in the app's own form and are never passed through the AI or the publish service, which is why your AI cannot connect a warehouse for you.

Open dashies.ai/app/connections, or use the account menu, then Data sources.

Every form has an optional Display name field, hinted Optional. Helps you tell data sources apart. and capped at 120 characters. Set it if you will have more than one.

Two connect shapes

Which one you get depends on the engine, and it changes what you do after clicking Connect.

Shape	Engines	What happens
Connect, then Test	PostgreSQL, SQL Server	Creating the data source proves Dashies can reach the warehouse and leaves it pending. You then click Test to run a real query and move it to active.
Connect only	BigQuery, Snowflake, Amazon Redshift, Databricks, Oracle Database	Creating the data source runs the verification in the same round trip and comes back already active, with the databases or datasets it found. Oracle Database has a third outcome: where the verification cannot get an answer in time the data source is saved and reads Still testing, and it may settle on its own. It also lists nothing back, by design.

Limits that apply to every engine

• Ten warehouse data sources per workspace. The eleventh is refused with You have reached the maximum number of warehouse data sources. Each workspace counts separately, so a free slot in one is not a free slot in another. Every data source that is not disabled counts, pending ones included - the cap is not a count of the active status this page names above, so ten that never passed Test still fill the workspace.
• Twenty connection changes per minute. Past that you get Too many connection changes. Wait about a minute and try again.
• Credentials go into Supabase Vault. The stored row keeps a pointer to the encrypted secret plus non-secret settings such as the host and database name. The secret value never appears in the row, an API response, a log line, or an audit entry.
• Failures never echo your host, login, or driver text. Every failure is recorded as a short fixed token such as connection_auth or schema_drift, chosen from a closed set. The set of tokens grows as new kinds of failure get their own name, so this page does not list it; the run history names the token it recorded, and Refresh failure classes explains the ones about your warehouse. Two tokens are about OUR side rather than yours and are not on that page yet: extractor_host means the machine that runs your extract had a problem, and audit_refused means our own checks declined to publish a refreshed copy. Neither is a fault in your data source, and on both your dashboard keeps serving its last good numbers.

Two status fields, and why both exist

Each data source shows two independent facts. They disagree normally, and that is not a bug.

• Status is what an explicit Test concluded: pending, active, or error. That test may be days old.
• Health is what the refresh cron or an authoring call last actually observed: ok or failing.

active plus failing is a normal reading. It means the last Test passed but a real query since then did not, which usually means a credential expired or was rotated. Health gates nothing.

Check it worked

1. The data source's status reads active on dashies.ai/app/connections.

2. Ask your AI tool to list connections and introspect the schema:

   List my Dashies connections, then introspect the schema of the warehouse one.

   You should get back the tables and columns of the schemas, datasets, or catalogs you allowlisted. An empty schema list means the login can reach the server but cannot see your tables, so re-check the grants on that page's setup script.

3. Then author a dashboard against it.