--- title: Is Dashies right for you? description: Honest fit and anti-fit. What Dashies is good at, what it deliberately does not do, and the limits that decide it for you. updated: 2026-09-22 --- Read this before you install anything. Every limit below is a real property of the product today, not a roadmap gap being softened. If one of them is disqualifying, it is cheaper to know now. ## Dashies fits well when - **Your data is in a supported source**: PostgreSQL, BigQuery, Snowflake, Databricks, Microsoft SQL Server or Oracle Database can publish on the served path today, and CSV / Excel uploads can back a dashboard too. Amazon Redshift can be connected, explored and validated, but cannot currently back a published dashboard. - **You already work through an AI tool** and want the dashboard authored there rather than assembled by hand in a BI tool. - **The dashboard is read by people opening a link.** Readers hold a viewer seat rather than a creator seat, and a viewer seat costs less on either paid plan. See [Seats](/concepts/plans-and-gating#seats). - **The numbers move on a business cadence**, not by the second. Hourly, daily, weekly and monthly are the normal cases. - **You want a specific look.** Dashies ships arbitrary HTML rather than a fixed widget vocabulary, so a dashboard can look like your company rather than like a BI tool. - **You are replacing a deck someone rebuilds by hand every month.** That is the clearest win: the rebuild stops happening. ## Dashies does not fit when ### You need row-level security per viewer and you are not on Enterprise Per-viewer filtering exists, and it is an **Enterprise** capability on a **workspace** dashboard reading a warehouse: the dashboard declares which column decides who may see a row and who is granted which values, and each viewer is served only their own rows. See [Row-level security](/reference/spec#row-level-security). Below Enterprise there is none, and the shape below is what you get instead. A published dashboard is one set of bytes served to everyone who can open it, so two people looking at the same dashboard see identical numbers, and access is all-or-nothing: a dashboard is visible to every current member of the workspace it lives in, and to nobody else. There is no share link, no per-viewer grant, and a signed-in non-member gets the same 404 as a URL that does not exist. If a sales rep must see only their own region and Enterprise is not on the table, you need one dashboard per region, each bound to a query that already filters. ### You need refresh faster than hourly The fastest cadence is **hourly**. Nothing here is live or streaming. A scheduled run starts on a grid rather than at an exact instant, so a `09:00` daily refresh begins within roughly half an hour of `09:00`. [Schedules](/concepts/schedules) states the precision honestly. If you need a number that is seconds old, or a page that updates while someone is watching it, this is the wrong tool. ### Your database only accepts known addresses, and it is not SQL Server, Oracle or PostgreSQL Dashies connects to SQL Server and Oracle Database from two fixed addresses per region, and to a PostgreSQL database from the same two when you add it as only accepting known addresses, so a firewall that admits only known addresses can admit Dashies: [IP addresses](/reference/ip-addresses) lists them. Snowflake, BigQuery and Databricks do not connect only from those addresses yet, so an account that admits only known addresses cannot be reached from Dashies. A database with no route in from the internet at all, reachable only over a VPN or a private network, is out of reach on every engine. Both are real limitations rather than something better SQL fixes. **This section was about SQL Server alone until 2026-09-22**, and said that on some placements Dashies did not connect from a fixed address, so only a wide firewall rule admitted it. That stopped being true when every region got its fixed pair. What is still narrower on SQL Server is on [Connect SQL Server](/guides/connect-warehouse/sqlserver): two statement shapes that are refused, four column types that cannot be carried, and a case-insensitive default collation that merges rows inside your server before Dashies sees them. **It said SQL Server "has no Parquet offload at all" until 2026-09-11.** That was true and is not: a SQL Server dashboard is served like the other warehouse engines, so its data is held by Dashies rather than shipped inside the file, and the 5,000-row executor cap bounds the authoring tools rather than that dashboard's own data. ### Your dashboard needs to call an API when someone opens it Every served dashboard runs in a sandbox on an opaque origin. It cannot use `localStorage`, `sessionStorage`, cookies, or IndexedDB, and it cannot make a same-origin authenticated request. Everything a viewer sees comes from data that was already inside the file. This is deliberate: without it, a published dashboard would share an origin with the Dashies web app and could read a viewer's session out of it. But it does rule out a dashboard that fetches something live at view time. ### Nobody on the team uses an AI tool There is no authoring UI. You cannot build a dashboard by clicking around in the web app, and there is no plan to add one: the whole design assumes your AI tool is the authoring surface. Someone on the team has to be driving Claude Code, Codex, Cursor, or another plugin-capable agent. ### You need to trigger a refresh from CI today There is a headless HTTP endpoint for triggering a refresh, but **there is no way to create an API key in the app**, so it is not usable in practice yet. If your plan depends on a pipeline kicking a refresh after a nightly load, that is not available today. Refresh on a schedule, on demand in the web app, and on demand through your AI tool all work. ## Limits that are worth knowing, but rarely disqualifying - **Your account handle is permanent.** It is derived from your email address at signup and there is no rename path. If you need a chosen label in the URL, create a workspace: a workspace slug is yours to pick. - **Approximate aggregates are rejected** where exactness is being promised. This matters most on BigQuery, which has no exact percentile function, so a percentile dashboard there has to ship row-level data rather than a precomputed lattice. See [Datasets and the four modes](/concepts/dataset-modes). - **Multi-select and range filters cost more.** A dashboard whose filters are all single-select can ship a small precomputed artifact. Multi-select over a non-additive measure needs a heavier one. Same page as above. - **The web app's version history page shows the workspace you are switched into.** Your AI reaches any workspace's history through the MCP tools. - **Refreshing on demand needs a paid plan**, and so does connecting a warehouse or setting any cadence other than manual. Publishing dashboards and sharing them with your workspace do not. See [Plans and what is gated](/concepts/plans-and-gating). ## If you are not sure The cheapest test is the [Quickstart](/start/quickstart). It uses the built-in `self` connection, needs no warehouse and no paid plan, and ends at a live URL. It will tell you within one session whether the authoring loop feels right.