Data sources overview
A data source is a saved connection to a database, warehouse, or endpoint — the thing your queries actually run against. This page covers the parts common to every connector; for the exact fields a specific connector asks for, see its own page under Connecting Data.
Creating a connection
Add a data source, pick a connector type, and fill in its connection fields (host, credentials, database name — the exact set varies by connector). Passwords and other secrets are stored encrypted and are never echoed back by the API once saved — the edit form shows every other field, but not the secret itself.
[!NOTE] Creating a data source requires having at least one group that both grants the create-data-source permission and is itself unrestricted. If your access is limited to specific data sources, ask a workspace admin to widen it rather than trying to create one yourself.
Testing a connection
Before or after saving, you can test a connection — arcodash opens it and runs a trivial query
(effectively SELECT 1, or the connector’s closest equivalent) to confirm the credentials and
network path work. A test can run against a not-yet-saved configuration (useful while filling out
the form) or against an already-saved data source’s stored options.
A failed test returns a human-readable error — bad credentials, an unreachable host, or a misconfigured field — without ever leaking the configured secrets back into the error message.
Schema introspection
Once connected, arcodash can introspect the schema: every table/collection/index visible to the configured user, with its column or field names. This populates the schema browser in the query editor so you can see what’s queryable without leaving arcodash. Schema is cached rather than fetched on every page load — request a refresh explicitly when the underlying source’s structure has changed, rather than waiting for it to happen automatically.
[!NOTE] If nothing’s cached yet, opening the schema browser triggers an automatic first fetch — but only for someone whose role can edit the data source. A viewer without that permission just sees an empty schema in the same situation, until a teammate who can edit the data source opens it and the fetch happens on their behalf; from then on, everyone sees the same cached schema. This is why a colleague can see a table you can’t, the first time either of you opens a freshly connected data source.
Pausing and resuming
A data source can be paused with an optional reason, and resumed later. This is a visible signal on the data source (and the reason, if you set one) rather than a delete — the connection’s configuration is untouched, so resuming brings it right back without re-entering anything.
[!TIP] Pausing is useful for a connection you know is temporarily unreachable (a maintenance window, a credential rotation in progress) — mark it paused with a reason so anyone else looking at it understands why, instead of just seeing a mysterious test failure.
Editing vs. deleting
Editing a data source updates its name, type, or connection options in place — anything built on top of it (queries, dashboards) keeps working against the same data source id. Deleting removes the data source entirely; there’s no undo, so pausing is usually the safer move if you’re not sure you want it gone for good.
Access is scoped by group
Not everyone in an organization necessarily sees every data source — which ones a user can see and query is determined by their group memberships, not set per-user. See Groups and data source access for how group-based data source access control works, including the restricted/unrestricted distinction and how access from multiple groups combines.
Where to go next
- Query Results (meta-source) — join across your other queries’ cached results without a real database connection.
- Pick a connector from the sidebar for its exact connection fields and example configuration.