> ## 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.

# Database connectors

> Connect Summand to PostgreSQL, MySQL, Snowflake, or Azure SQL for live, refreshable analysis.

Database connectors let Summand query a live warehouse and refresh analysis on demand. Available on **Enterprise** plans.

## Supported engines

<CardGroup cols={2}>
  <Card title="PostgreSQL" icon="elephant" href="/data-sources/databases">
    Versions 11+. Read-only credentials recommended.
  </Card>

  <Card title="MySQL" icon="database" href="/data-sources/databases">
    Versions 5.7+ and MySQL 8. Compatible with MariaDB.
  </Card>

  <Card title="Snowflake" icon="snowflake" href="/data-sources/databases">
    Username + password authentication.
  </Card>

  <Card title="Azure SQL" icon="cloud" href="/data-sources/azure-sql">
    Azure SQL Database and Managed Instance.
  </Card>
</CardGroup>

For Databricks (with UniForm), see [Delta Sharing](/data-sources/delta-sharing). For Databricks without UniForm, Redshift, BigQuery, Oracle, and SaaS sources, see [Fivetran](/data-sources/fivetran).

## What Summand needs

A user with **read-only access** to the schemas and tables you intend to analyze. Specifically:

* `SELECT` on the target tables
* `USAGE` on the schemas (Postgres / Snowflake)
* `INFORMATION_SCHEMA` access for schema discovery

Summand never executes writes, never reads system catalogs beyond `INFORMATION_SCHEMA`, and never executes user-supplied SQL.

## Network access

Summand connects from a fixed set of egress IPs — share these with your network team to allowlist:

* `52.x.x.x/30` (production)
* `54.x.x.x/30` (production failover)

<Note>
  Live IP ranges are listed in the in-product **Settings → Connectivity** panel for your account. The values above are illustrative — always copy the live ones from there.
</Note>

For databases inside a VPC with no public access, Enterprise customers can request:

* **PrivateLink** (AWS) — Summand creates a VPC endpoint in your account.
* **VPC peering** (AWS, GCP) — for ongoing high-throughput workloads.
* **SSH tunnel** — supported but not recommended for production.

Contact [sales@summand.com](mailto:sales@summand.com) for any of the above.

## Setup

<Steps>
  <Step title="Create a read-only user in your database">
    Use the SQL appropriate for your engine. For Postgres:

    ```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;
    ```
  </Step>

  <Step title="Add the connector in Summand">
    From the **Connectors** page, click **Add connector → PostgreSQL** (or MySQL / Snowflake). Provide host, port, database, and the read-only credentials. Summand validates connectivity before saving.
  </Step>

  <Step title="Pick tables">
    Summand discovers all tables you have `SELECT` on. Choose which ones to enable as datasets. You can enable more later from the connector page.

    Each enabled table becomes a dataset. Baseline column-stats run automatically. From there, [chat](/guides/ask-summand), [create views](/guides/create-a-view), or [set up experiments](/guides/set-up-an-experiment) — there's no per-dataset configuration step.
  </Step>
</Steps>

## Refresh

Click **Refresh** on a dataset to re-run analysis against the current state of the source table. Refresh:

* Streams the table to Summand's curated Parquet store
* Fits a fresh EBM and re-runs surprise finding
* Writes a new semantic-layer version
* Switches the UI to the new version on success

The previous version is preserved for comparison. There is no automatic refresh today — refresh is always user-initiated.

## Credential handling

* Database passwords are encrypted with AWS KMS and stored in AWS Secrets Manager.
* Plaintext credentials are never logged.
* Connection strings are never exposed in the UI or API responses.
* You can rotate credentials at any time from **Settings → Connectors → Edit**.

## Removing a connector

Deleting a connector immediately revokes all access to the underlying datasets and queues their data for deletion. Datasets can be re-created if you re-add the connector with the same credentials, but their analysis history is lost.