Data handling & privacy
This page states plainly what data arcodash sees, what it stores and for how long, what’s encrypted, and what telemetry exists. It describes what the software actually does, if you’re running a security review, this is the page to hand your reviewer.
What arcodash sees when you connect a source
Connecting a database gives arcodash two kinds of access, and it’s worth being precise about each:
- Credentials, host, username, password, and the rest of the connection options are encrypted with AES-256-GCM before they’re written to the database, and are never returned by the API once saved. The edit form re-displays every non-secret field; secret fields are stripped server-side before the response is built, so there is no API call, admin or otherwise, that reads a saved password back out.
- Your data, query results flow through arcodash when a query runs, and the result is cached (see below). arcodash does not copy, sync, or index your database beyond that. The one exception is the optional data source AI profile, which samples up to 200 rows per table into a stored digest.
Testing a connection runs a trivial probe (effectively SELECT 1); a failed test returns the
error without echoing configured secrets into the message.
For the CSV and SQLite file-upload connectors, the uploaded file itself is the data source. It is stored in arcodash Cloud’s object storage (Google Cloud Storage, which encrypts stored objects by default), scoped to your organization.
What’s cached, where, and for how long
Caching exists for performance, so a dashboard doesn’t hammer your warehouse on every page load. Three things are cached or stored:
Schema metadata
When a connector’s schema is introspected, the result, table and column names, is saved on the connector’s own database row, per organization. It has no expiry: it stays until it is refreshed: explicitly from the schema browser, automatically the first time the schema browser is opened with nothing cached yet, or, for organizations that have used the AI features in the last 30 days, by a daily schema-only refresh of each non-paused source (metered warehouses such as BigQuery, Athena, Snowflake, and Redshift are excluded, because even schema reads are billed there). See Connectors overview for the permission details of who can trigger a refresh.
AI profile
For AI features, arcodash can store a profile of a data source on the connector’s own database row: table and column names, relationships between tables, AI-written table and column descriptions, and, from the data pass, a per-column digest built from up to 200 sampled rows per table (null fraction, distinct count, the five most common values truncated to 40 characters, and min/max). The profile lives unencrypted at the application layer in arcodash’s Postgres database, like schema metadata, and is deleted with the data source. The sampled digest holds real values from your tables, so treat it like cached query results.
Query results
When a query runs, its result rows are stored in arcodash’s own Postgres database, together with the SQL text that produced them, keyed by a hash of the query text and parameters. One cached result exists per unique query per connector, re-running the same query replaces the previous cached result rather than accumulating copies.
- Reuse window: by default, requesting a query’s result reuses the cached copy if it’s
less than 24 hours old; otherwise a fresh run is triggered. Passing
max_age=0on an execution request always forces a fresh run. - Expiry: there is no automatic deletion. A cached result remains until the same query runs again and replaces it.
- Access control: cached results are gated at read time by the same group-based connector access as live queries, fetching a result checks that one of your groups has the result’s connector in scope, so a cached result never lets someone read data from a connector their groups don’t grant. Admins can read any result in their organization. See Groups and connector access.
The Query Results meta-source reads these same cached results, org-scoped, loaded into a temporary in-memory SQLite instance for the duration of the query, not persisted anywhere new.
What’s encrypted at rest
Three kinds of secrets are encrypted with AES-256-GCM (a random 96-bit nonce per encryption, key held outside the database) before storage:
- Connector credentials, the connection options of every data source.
- AI provider API keys, the Gemini/OpenAI/Anthropic keys configured in AI provider configuration. The API reports only whether a key is configured and where it came from, never the key itself.
- Notification destination secrets, webhook URLs and similar credentials for alert destinations.
User passwords are not encrypted but hashed, with Argon2id, the standard one-way construction for login credentials; arcodash cannot recover a password, only verify it.
Schema metadata and cached query results are stored unencrypted at the application layer, in arcodash’s Postgres database (arcodash Cloud’s underlying disks are encrypted at rest by Google Cloud as a platform default).
What the AI features send
Nothing is sent anywhere unless your organization configures an AI provider key; without one the features are simply off. With a key, each feature sends the following to your organization’s configured provider, using your organization’s own key. Most of it is schema-level metadata, but two features can send row-level values, and the table says which.
| Feature | What’s sent | Row-level values? |
|---|---|---|
| Ask with AI (and Fix with AI) | Your question; table and column names with types; per-column notes from the AI profile (descriptions, relationships, and, if the sample-values toggle is on, a few sample values and min/max per column); the SQL in the editor; your recent saved queries (names and SQL, capped at about 2 KB); and, on a retry, the database error message. Preview rows from the read-only run are shown to you and never put in a prompt. | Only sampled column values, and only with the toggle on |
| Auto Visualize | Column names and types plus the row count of a result | No |
| Suggest checks with AI | Table and column names, declared column types, the same AI profile notes as Ask (sample values included only with the toggle on), and your 5 most recent saved queries on that source (names and SQL, capped at about 2 KB) | Only sampled column values, and only with the toggle on |
| Data source AI profile: descriptions | Table and column names with types and, with the toggle on, column stats and the sampled values per column, so the model can write a description for each column | Only sampled column values, and only with the toggle on |
| Alert explanations (“Why did this fire?”) | The monitor’s SQL, the schema and profile notes (as above), the monitor’s last 30 observed values with timestamps, and the results of up to three read-only queries (the model is asked to aggregate, but this is not enforced, so results can include individual row values) the model proposes and arcodash runs on your source (at most 50 rows each, about 4 KB of result text in total) | Yes: query results, normally aggregates such as counts per segment, up to 50 rows per query |
The data pass of the AI profile itself (sampling rows from your tables) happens inside arcodash: the sampled rows are digested there and never sent to the provider directly. Views are never sampled. Metered warehouses (BigQuery, Athena, Snowflake, Redshift) are sampled only when someone explicitly asks for a full data pass, and BigQuery samples carry a bytes-billed cap so an oversized scan fails instead of running up a bill.
Controls
Both controls are in AI Settings → Data sent to AI and require an admin.
- Include sample values in AI prompts (on by default). Turning it off removes sampled values and min/max from every prompt above. The null fraction is still used, and descriptions that were written from sampled values are withheld from prompts.
- Explain alerts with AI (on by default). Turning it off stops the alert investigation entirely, so no investigation query results are sent for alerts. It also requires the sample-values toggle: with sample values off, no alert investigation runs either, and alerts keep only the plain statistics line described in Alerts overview. An investigation also needs a built AI profile for the monitor’s data source.
Threshold-free (baseline) monitors do not call an AI provider at all: they are a statistical calculation over the monitor’s own recorded values.
Per-request token counts, provider, model, and success/failure are recorded for the usage view; the prompt text itself is not stored, and prompts, sample values, and rows are not logged. See AI-assisted SQL generation for the feature itself.
Telemetry
- Marketing website (arcodash.com): PostHog, hosted in the EU (
eu.i.posthog.com) - capturing is opted out by default and nothing is sent until you accept the banner, and Google Analytics 4, which isn’t even requested from the browser until you accept. Declining the banner keeps both off entirely. - Dashboard app: the same PostHog EU project, with the same consent gate, the analytics SDK is not even downloaded until consent is granted, session recording is disabled outright, and URLs are scrubbed of credential-bearing tokens (password-reset tokens, invitation tokens, public-share tokens) before any event leaves the browser. After sign-in, events are associated with your user id, email, and organization. Declining the banner keeps analytics off entirely.
- Backend: the server records a short, fixed list of product events to the same PostHog project, not gated by the browser consent banner because they contain no page or browsing data: an AI usage event (provider, model, feature, token counts, no prompt text) and a connection-test event (connector type and whether the test succeeded, no credentials, no hostnames). With no PostHog key configured, every one of these is a no-op and nothing is sent.
There is no other analytics, error-tracking, or telemetry vendor in the product, no Sentry, no session replay, no third-party tag managers, and no analytics vendor at all in the dashboard app beyond PostHog.
What’s logged
The audit log records administrative and security-relevant actions, user, group, role, connector, monitor, and destination changes, plus query executions. Two things worth knowing beyond that page:
- A query-execution entry records that a query ran (who, which connector, which result) - not the SQL text and not the result data. A failed execution’s entry does include the error message returned by your database.
- Entries are append-only and are not deleted: there is no retention window or automatic purge.
The audit log is readable by organization admins only.
Query SQL text does live elsewhere by design: alongside its cached result, and in a query’s own version history. That’s the product’s own data model, not telemetry, it never leaves your arcodash deployment.
Where data lives
arcodash runs on Google Cloud in the europe-west4 region (Netherlands): the application
database, cached query results, and uploaded files all live there. The analytics project,
where enabled, is PostHog’s EU cloud.
Where to go next
- Audit log, the full list of recorded actions.
- Groups and connector access, the access model that cached results inherit.
- AI provider configuration, configuring, testing, and revoking provider keys.