Skip to main content
Use database integrations to import the result of a query into Dawn. Start with a dedicated read-only account and a small query before importing a large table.

​
Shared setup

  1. Ask your database administrator to provision the account and required source permissions.
  2. Confirm that the database endpoint is reachable from the integration environment. Ask support for the relevant network requirements if your database is private or IP-restricted.
  3. Open Connections → New connection, select the source, and fill in the fields below.
  4. Select or create the matching credential and save the connection.
  5. Build an import using a query and output dataset name.
  6. Run it and compare the output with the same query in the source system.
Use the source database’s SQL dialect. A query used to import from SQL Server can differ from a transformation query run on a dataset already in Dawn.

​
Postgres

Connection: Host, Port (normally 5432), Database, and Default schema. Credential: Username and password. Arrange database connection access, schema usage, and SELECT access to the required tables or views. These are source-side grants; entering a schema in Dawn does not grant access or restrict the account to it. Example import query, replacing the table and columns with your own:
If authentication succeeds but no tables can be read, check schema and table permissions. If the connection times out, check the host, port, firewall, and network route.

​
Microsoft SQL Server

Connection: Server, Database, and Default schema where needed. Credential: Username and password. Grant the login access to the intended database and read access to the required tables or views. Use T-SQL for the import, for example:
Confirm the server name and database separately. A valid server login does not necessarily have permission to read the selected database.

​
Snowflake

Connection: Account identifier, Database, Default schema, and optionally Warehouse and Role. Credential: Username and password. Use a role with access to the database and schema, SELECT on the required tables or views, and USAGE on the query warehouse. Have your administrator confirm that the account’s authentication policy supports this credential flow. Specify a warehouse that the role can use. A successful login can still produce a query error if the selected role cannot use the warehouse or access a table.

​
Google BigQuery

Connection: Location matching the data you will query. Credential: Google Cloud service account key. Create the credential using the service-account-key form and supply the service account JSON there. A typical import setup needs:
  • BigQuery Job User (roles/bigquery.jobUser) on the project running the query.
  • BigQuery Data Viewer (roles/bigquery.dataViewer) on the source dataset or appropriate source resources.
  • BigQuery Read Session User (roles/bigquery.readSessionUser) on the project used for read sessions when fetching results through the Storage Read API.
The connector creates its query client using the service account’s project. Arrange grants accordingly, including cross-project source access if applicable. These roles have different purposes; query-job permission alone does not grant access to table data. See Google’s role reference. Use GoogleSQL and fully qualified table names where appropriate:
A location mismatch can fail even when permissions are correct. Confirm the dataset’s region or multi-region before changing the connection.

​
Microsoft Fabric Warehouse

Connection: SQL endpoint and Warehouse name. Credential: Application client ID and client secret. The connector authenticates as an Entra service principal through the SQL endpoint. Ask your Fabric administrator to enable the required service-principal access and grant read access to the intended warehouse objects. Use a small T-SQL query first. Check tenant policy, warehouse access, and SQL object permissions independently if it fails. Do not assume a client ID and secret alone grant warehouse access.

​
Make the import repeatable

Choose explicit columns and filters instead of importing everything by default. Record the source timezone and the meaning of each date filter. Validate how the destination behaves on a second run before scheduling it. Continue with data engineering to clean and join the imported results, or permissions and credentials to rotate access.