# How to Connect a Warehouse to Lookout


{{< customreadfile "/includes/lookout/beta-callout.md" >}}

The Lookout agent requires access to your data warehouse to answer questions about your data. 

The agent lists tables, inspects schema, and runs SQL to answer questions, build dashboards, and investigate your pipelines. The results flow straight into charts, tables, metrics, and funnels.

Lookout supports the following warehouses:

- PostgreSQL
- Snowflake
- Redshift
- BigQuery
- Databricks
- ClickHouse

## Connect a warehouse

{{< info >}}
Only admins can create, connect, edit, and test a warehouse connection. See [Roles and Permissions]({{< ref "lookout/workspaces/roles.md" >}}) for more information.
{{< /info >}}

1. Go to **Settings** > **Connections** > **Warehouses**.
2. Select **Add account** and choose your warehouse type.
3. Enter the connection details and save.

Note that:

- Connected warehouses appear at the top of the page. 
- RudderStack destinations that are not yet mapped to a warehouse connection are listed under **Unmapped Destinations**, so you can see at a glance what is available to connect.

{{< image src="images/lookout/warehouse-account-settings.webp" >}}

## Best practices

Follow these best practices to ensure a smooth and secure connection to your warehouse.

### Dedicated read-only service account

For every warehouse, connect Lookout through a **dedicated service identity that has read-only access** rather than reusing a person's credentials or an account with broad privileges. This isolates RudderStack's access to your warehouse, keeps it strictly read-only, and makes it easy to audit or revoke independently of anyone's personal login.

Each platform has its own name for this kind of identity, but the principle is the same — create an identity, grant it read-only access to the data Lookout needs, and use it for the connection:

| Warehouse | Identity to create | <div style="width: 250px;">Access to grant</div> |
|-----------|--------------------|-----------------|
| **Snowflake** | Service user with a dedicated read-only role | `SELECT` on the relevant databases/schemas |
| **BigQuery** | Service account | Read-only roles (for example, Data Viewer + Job User) |
| **Databricks** | Service principal | Read-only grants on the relevant catalogs/schemas |
| **Redshift** | IAM service user / dedicated database user | `SELECT` on the relevant schemas |
| **PostgreSQL** | Dedicated database role | `SELECT` (read-only) on the relevant schemas |
| **ClickHouse** | Dedicated database user | `SELECT` (read-only) on the relevant databases |

{{< tip >}}
Scope the grant to only the databases, schemas, and tables Lookout needs. Read-only, least-privilege access keeps the connection's blast radius small.
{{< /tip >}}

Note that creating a service account, role, or user, and granting it read-only access usually requires warehouse-administrator privileges. If you don't manage your warehouse directly, reach out to your **Infra team** to have it set up. 

The exact credentials and permissions each warehouse needs are shown on its connection page in **Settings** > **Connections** > **Warehouses**.

### Allocate and isolate compute

The following recommendations help Lookout respond quickly while keeping costs predictable. They are written with Snowflake in mind, but the same principles apply to other warehouses — the exact settings may differ:

- **Assign enough compute**: Larger compute size means faster queries and quicker access to your data, which makes the agent feel more responsive.
- **Isolate the workload**: Where possible, point Lookout at a **separate, dedicated compute resource** rather than one shared with production jobs. This isolates Lookout's usage for cleaner cost attribution and avoids competing with other workloads.
- **Auto-suspend aggressively**: Configure the compute to shut down quickly when idle — for example, after **5 minutes of inactivity or less**. Because Lookout's usage is bursty, aggressive auto-suspend keeps costs low without affecting responsiveness.

## Read-only access

Warehouse access is strictly **read-only**. The agent can query and inspect your data, but it can't write to or alter your warehouse.

Note that:

- Dashboards store their **definition**, not their data — they re-run their queries on every load and store no result rows on RudderStack's servers
- Connection credentials are encrypted at rest

See [Security and Data Handling]({{< ref "lookout/security.md" >}}) for more information.

## Where warehouse data is used

Once a warehouse is connected, the same connection powers the following Lookout features:

- [Chat answers]({{< ref "lookout/working-with-lookout/chat.md" >}}): Natural-language questions answered with live queries
- [Dashboards]({{< ref "lookout/working-with-lookout/dashboards.md" >}}): Panels that re-run their queries on every load
- [Audiences]({{< ref "lookout/audiences/_index.md" >}}): Segments built from your warehouse data and kept in sync with destinations
- [Slack]({{< ref "lookout/integrations/slack.md" >}}): The same answers from a Slack DM or channel