Warehouse credentials

Every query Lightdash runs uses a warehouse account: one shared by everyone, each person’s own, or a mix of both. The setup you choose decides whether Lightdash or the warehouse controls who sees which data, and how much each person has to set up before they see a chart.

​

Choose a setup

Answer these questions in order and use the first setup that fits:

1. Does the warehouse need to control what each person can read, or log queries by person? If not, and Lightdash roles and user attributes are enough, use one shared connection.
2. Does everyone who needs different data have their own warehouse account? If not, personal credentials can’t separate them. Use one shared connection with user attributes where that’s enough, and a project per audience only as a last resort.
3. Do most people only view dashboards? If so, and your warehouse is Trino, Databricks, or BigQuery, use optional personal credentials.
4. Does your warehouse have a sign-in flow for personal credentials? If it does, use required personal credentials. If it doesn’t, requiring them means issuing a warehouse login to every viewer, so compare that with a project per audience.

​

One shared connection

Everyone queries as one warehouse account, set on the project connection. Make it a dedicated read-only account, not a person’s own sign-in. This fits when Lightdash roles are enough to control what people can do, and everyone in the project can see everything that account can read. Most teams start here: people see dashboards as soon as they’re invited, and scheduled deliveries, embedding, and service accounts work without extra setup. The warehouse sees one user, so its permissions can’t differ by person and its audit logs show only the shared account. Lightdash roles control who can explore or open the SQL runner, not which tables or rows the warehouse returns. Anyone with manage:SqlRunner can query everything the shared account can read. Developers and Admins have that permission by default. A custom role can leave it out, but it can’t remove a permission someone already has from their organization role. To limit what people see without changing the warehouse, use user attributes. They filter rows and hide fields in everything built from the semantic layer, but they don’t apply to raw SQL. Every warehouse supports this setup.

​

Required personal credentials

Each person queries as themselves, so the warehouse decides what they can read and logs their queries under their own account. Turn on Require users to provide their own credentials in the project’s warehouse connection settings, and everyone adds personal warehouse credentials. Choose this when access rules already live in the warehouse, you need per-person audit logs, or developers need raw SQL without seeing everything. It works best on a warehouse with a sign-in flow. Everyone has to add credentials before they see any data, including people who only view dashboards. With a sign-in flow, that’s one sign-in. Without one, each viewer needs a warehouse login issued for them. Some features work differently:

• Service accounts can’t run queries, so API and CLI scripts that query the project through one stop working.
• Embedding isn’t available, because embedded viewers can’t provide credentials.
• Scheduled deliveries run with their owner’s credentials, and fail if the owner’s are missing or expired.
• Pre-aggregates ignore personal credentials. A query that matches one returns the shared materialized results, whatever the viewer’s own account can read, so keep explores with restricted data out of pre_aggregates.
• Cached results are stored per person, so one person’s query doesn’t speed up anyone else’s.

The setting is on the connection form for BigQuery, Snowflake, Databricks, Redshift, PostgreSQL, Trino, and ClickHouse. The Athena and DuckDB forms don’t have it. Four warehouses have a sign-in flow for personal credentials:

• Snowflake: Sign in with Snowflake, once you add a security integration.
• Databricks: Sign in with Databricks, on instances with Enterprise enabled and an OAuth application.
• BigQuery: Sign in with Google.
• Redshift: Sign in with AWS, through IAM Identity Center. Everyone gets the one permission set fixed on the connection, so it replaces passwords but doesn’t give people different access.

Trino, PostgreSQL, and ClickHouse take a username and password.

​

Optional personal credentials

A shared connection serves most people, and anyone who adds personal credentials queries as themselves. It suits projects where most people view dashboards and a small group, usually developers or analysts, needs their own warehouse permissions. On warehouses that support it, choose this over required credentials: viewers need no setup, and service accounts and embedding keep using the shared connection. People add personal credentials themselves, so anyone who hasn’t still queries as the shared account, including SQL runner users. Limit the shared account to data every project member can see. Two people can also get different results from the same dashboard, or one can get a warehouse permission error, depending on whose credentials run the query. A query served from a pre-aggregate returns the same shared results to everyone, including people with personal credentials. Trino and Databricks use personal credentials whenever Require users to provide their own credentials is off. BigQuery uses them when you also turn on Use personal credentials when available in the connection’s advanced settings. Other warehouses use personal credentials only when the project requires them.

​

A project per audience

Each audience gets its own project, with a warehouse connection limited to the data that audience can see. This is rarely the right setup, and it shouldn’t be your first choice. Most teams that consider it are better served by one shared connection with user attributes, which separates what groups see without duplicating content. Use a project per audience only when groups must see different tables or datasets, don’t have warehouse accounts of their own, and user attributes can’t keep them apart, such as client teams that write their own SQL. Each project has its own spaces, charts, and dashboards, so content several audiences share is duplicated in each project, and every model change has to be deployed to each one. Promoting content copies individual charts and dashboards to another project, but keeping the copies in sync is up to you. Organization roles above Member apply to every project, so anyone who has one can open every audience’s project. Keep each audience at Member and give them a role in one project only. Each project can use any of the setups above, on any warehouse.

​

Add credentials for someone else

If someone can’t add their own credentials, an organization admin can impersonate them and add credentials under Settings → My warehouse connections. Impersonation is off until it’s enabled for your organization. Use a password, key, or token issued for that person. A Sign in with button saves whichever warehouse account your browser is signed in to, so it would store your identity under their name.