> ## Documentation Index
> Fetch the complete documentation index at: https://docs.summand.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect a database

> Step-by-step setup for live PostgreSQL, MySQL, or Snowflake analysis. Enterprise plans only.

Database connectors give Summand a live view of a warehouse. This guide walks through PostgreSQL end-to-end; MySQL and Snowflake follow the same shape with different SQL.

For databases not in this list (Databricks, Redshift, BigQuery, Oracle), see the [Fivetran connector](/data-sources/fivetran).

<Steps>
  <Step title="Confirm network access">
    Summand connects from a fixed set of egress IPs, listed in **Settings → Connectivity**. Allowlist them on your database firewall before continuing.

    For private databases — VPC-only, no public endpoint — Enterprise customers can use PrivateLink, VPC peering, or an SSH tunnel. Email [sales@summand.com](mailto:sales@summand.com) to set this up; it takes about a day.
  </Step>

  <Step title="Create a read-only database user">
    Run the SQL appropriate for your engine. Postgres example:

    ```sql theme={null}
    CREATE USER summand_reader WITH PASSWORD '<strong-password>';
    GRANT CONNECT ON DATABASE your_db TO summand_reader;
    GRANT USAGE ON SCHEMA public TO summand_reader;
    GRANT SELECT ON ALL TABLES IN SCHEMA public TO summand_reader;
    ALTER DEFAULT PRIVILEGES IN SCHEMA public
      GRANT SELECT ON TABLES TO summand_reader;
    ```

    Snowflake equivalent:

    ```sql theme={null}
    CREATE ROLE summand_reader;
    GRANT USAGE ON WAREHOUSE compute_wh TO ROLE summand_reader;
    GRANT USAGE ON DATABASE your_db TO ROLE summand_reader;
    GRANT USAGE ON SCHEMA your_db.public TO ROLE summand_reader;
    GRANT SELECT ON ALL TABLES IN SCHEMA your_db.public
      TO ROLE summand_reader;
    GRANT SELECT ON FUTURE TABLES IN SCHEMA your_db.public
      TO ROLE summand_reader;
    CREATE USER summand_user PASSWORD = '<strong-password>'
      DEFAULT_ROLE = summand_reader;
    GRANT ROLE summand_reader TO USER summand_user;
    ```

    Use a long random password — at least 32 characters. Summand stores it encrypted in AWS Secrets Manager.
  </Step>

  <Step title="Add the connector in Summand">
    Go to **Connectors → Add connector → PostgreSQL** (or MySQL / Snowflake). Provide:

    * Host
    * Port (5432 for Postgres, 3306 for MySQL, your account URL for Snowflake)
    * Database name
    * Username and password from the previous step

    Click **Test connection**. Summand opens a connection, runs `SELECT 1`, and reports success or a clear error.
  </Step>

  <Step title="Pick tables">
    Once connected, Summand queries `INFORMATION_SCHEMA` and lists every table the user can read. Toggle on the tables you want as datasets — you can enable more later.

    Each enabled table becomes a dataset. The baseline column-stats component runs automatically; no other configuration is required.
  </Step>

  <Step title="Pick what to do next">
    From any dataset's detail page:

    * **Chat** with Summand for ad-hoc questions.
    * **Create a view** to save a SQL transformation, including cross-table joins.
    * **Set up an experiment** to schedule the Predictors, Surprise finding, or other components on the dataset (or on a view of it).
  </Step>

  <Step title="Refresh on demand">
    Click **Refresh** on any dataset to re-read current data from the source. Scheduled experiments will pick up the new data on their next tick. The previous semantic-layer version is preserved for comparison.
  </Step>
</Steps>

## Performance tips

* **Limit row count for huge tables.** A 100M-row table will take a long time to refresh. If you only need a representative sample, create a database view that samples or filters, and point Summand at the view.
* **Pre-aggregate via Summand views.** If multiple experiments target the same cohort, define the cohort once as a [view](/guides/create-a-view) and point experiments at the view rather than re-filtering in each component.
* **Refresh during off-peak hours.** A refresh is a single full table read. For warehouses with concurrent workloads, schedule analysis around your peak.

## Security review checklist

If you need to walk security through the integration:

* ✓ Read-only credentials, scoped to the schemas you grant
* ✓ Credentials stored encrypted in AWS Secrets Manager (KMS-backed)
* ✓ TLS required for all database connections; cert validation enforced
* ✓ Egress from a fixed IP range we publish
* ✓ No write paths exist in code — `SELECT`-only is a hard property of the connector, not a configuration
* ✓ Audit log entries for every connector create / update / delete (Enterprise tier)