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: no background crawl, no sampling, no row-level data leaves the query path.

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. Two things are cached:

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 someone refreshes it, either explicitly from the schema browser or automatically the first time the schema browser is opened with nothing cached yet. There is no background job that re-fetches schema on its own. See Connectors overview for the permission details of who can trigger a refresh.

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=0 on 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

Every AI feature sends schema-level metadata to your organization’s configured provider — never row-level data:

Feature	What’s sent
Generate SQL	Table and column names (not even column types), plus your question
Auto Visualize	Column names and types plus the row count of a result — never row values
Suggest data-quality checks	Table and column names, with declared column types where the connector reports them

Nothing is sent anywhere unless your organization configures an AI provider key; without one the features are simply off. Per-request token counts, provider, model, and success/failure are recorded for the usage view — the prompt text itself is not stored. 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 currently 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.