Connecting Data Sources - Orion Public Docs

These guides walk through what Orion needs to connect to each supported data source, and how to grant that access. Most connections are configured once at the tenant level by an administrator. Every guide ends the same way: take the connection details you produced and enter them in Orion under Configuration → Data Sources → Add Data Source. See Data Sources Management for a tour of that page. If you’d rather not enter them yourself, share the details with your Gravity contact and we’ll configure the connection for you.

How Orion connects

A few principles apply to every connection:

Read-only

Orion only ever issues read queries (SELECT and metadata introspection). It never runs DDL, DML, or stored procedures against your systems.

Least privilege

We recommend a dedicated service user or service account scoped to just the data you want Orion to analyze.

Encrypted at rest

Any credentials you share (passwords, keys, secrets) are encrypted at rest in our database.

For private databases that aren’t publicly reachable (behind a VPC, private subnet, firewall, or VPN), allowlist Orion’s egress IPs so we can reach them. All Orion services egress through the same set of IPs, so a single allowlist entry covers everything. Your production egress IP range is provided by your Gravity contact during onboarding.

Choose your data source

BigQuery

Snowflake

Databricks

Looker

PostgreSQL

MySQL

Redshift

Amazon Athena

Microsoft Fabric

Delta Lake

MotherDuck

dbt

News API

Weather

BigQuery

Orion connects to BigQuery using service account impersonation. You create a service account in your project and grant Orion’s service account permission to impersonate it. No credentials or keys are ever shared.

For every Google Cloud Console step below, make sure you are in the correct GCP project. Most setups use a single project for both the service account and the source data. If your datasets live in a different project from the one that runs Orion’s queries, see Querying datasets in another project.

Create a service account

Go to Google Cloud Console → IAM & Admin → Service Accounts
Click Create Service Account
Name: external-orion-data-access (or your preferred naming)
Description: “Service account for Orion data access”
Click Create and Continue
Skip role assignment for now → click Done

We’ll refer to this as the BigQuery Service Account going forward.

Enable service account impersonation

Orion queries BigQuery by impersonating the service account you just created. To allow that, grant Orion’s own service account the Service Account Token Creator role on it.Orion shows you the address to use. Go to Configuration → Data Sources, click Add Data Source, and choose BigQuery. The Orion Service Account sits under the Service Account Email field, with a button to copy it.Then, in Google Cloud Console:

Navigate to IAM & Admin → Service Accounts
Find the BigQuery Service Account you just created
Select the Principals With Access tab and click Grant Access
Add principal: the Orion Service Account address you copied
Assign role: Service Account Token Creator
Click Save

Create a scratch dataset and grant edit access

Navigate to BigQuery
Create a new dataset, a dedicated dataset reserved for Orion’s use (we recommend a descriptive name like orion_scratch)
Grant the BigQuery Service Account Data Editor access to this dataset

The scratch dataset must be in the same region (or multi-region) as the datasets you wish to query via Orion.

Orion uses this dataset to efficiently stream query results to a binary format optimized for quick analysis. Temp tables created here are automatically cleaned up.

Grant table-level access

In BigQuery, for each dataset or table you want to share:

Select the dataset → click Share Dataset
Add the BigQuery Service Account email
Assign role: BigQuery Data Viewer
Click Add, then Done

Grant project-level access

Navigate to IAM
Locate your BigQuery Service Account and click Edit
Assign these roles:
- BigQuery Job User
- BigQuery Read Session User
- BigQuery Resource Viewer (optional, recommended)
- BigQuery Connection User (optional, only for external tables and federated queries)
Click Save

BigQuery Job User and BigQuery Read Session User let Orion run queries and stream results. BigQuery Resource Viewer is optional but recommended. It lets Orion read project query history, which powers usage intelligence: Orion learns which tables, columns, and joins your team already relies on, and brings that knowledge to every analysis. BigQuery Resource Viewer provides bigquery.jobs.listAll, while BigQuery Job User provides bigquery.jobs.create.

Without BigQuery Resource Viewer, the connection test passes and queries run normally. Usage intelligence stays unavailable until you grant the role on every project whose query history Orion collects.

BigQuery Connection User (roles/bigquery.connectionUser) is only needed if Orion should query data through a BigQuery connection. That includes external tables over object storage, such as Cloud Storage BigLake tables, or federated queries against other databases with EXTERNAL_QUERY, such as Cloud SQL, Spanner, or AlloyDB. If you only query native BigQuery tables, skip it. Where you do need it, you can grant it on the specific connection instead of the whole project. See Google’s guides to working with connections and default connections.

Enter the connection in Orion

In Orion, go to Configuration → Data Sources, click Add Data Source, and choose BigQuery. The form asks for exactly what the steps above produced:

Field	From
Project ID	The GCP project that runs Orion’s queries: where the service account, scratch dataset, and query jobs live
Service Account Email	The BigQuery Service Account from step 1
Scratch Dataset	The dataset from step 3
Data Project ID (optional)	The GCP project where your source datasets live, if it differs from Project ID. Leave blank when everything is in one project
Location	The GCP location of your datasets (defaults to the `US` multi-region)

The Configure BigQuery Connection form in Orion, with the Orion Service Account shown under the Service Account Email field — Configure a BigQuery connection

The Orion Service Account shown on this form is Orion’s own address, the one you granted access to in step 2. You do not enter it anywhere. Your instance has its own address, so copy it from your own screen rather than from the picture above.No credentials need to be shared.

One project or two? Most customers keep the service account, scratch dataset, and source data in a single project and leave Data Project ID blank. Fill it in only when your datasets live in a different project from the one running Orion’s queries. See Querying datasets in another project.

Querying datasets in another project

Orion separates the project that runs your queries from the project that stores your data. The two roles map to the two form fields:

Project ID is the compute and billing project. The service account, the scratch dataset, and every query job live here. Grant BigQuery Job User and BigQuery Read Session User on this project (step 5), and BigQuery Connection User only if you use external tables or federated queries, plus Data Editor on the scratch dataset (step 3). Add BigQuery Resource Viewer here if you want usage intelligence.
Data Project ID is where your source datasets live. Grant the service account BigQuery Data Viewer on those datasets (step 4).

When both are the same project, leave Data Project ID blank and Orion uses Project ID for everything. When your data lives elsewhere, set Data Project ID to that project. Orion then qualifies your tables against it while still running jobs and writing scratch results in Project ID. The service account still only needs impersonation set up once, in the project where it was created.

Usage intelligence permissions

Usage intelligence is optional but recommended. With it, Orion reads BigQuery job metadata to learn which tables, columns, and joins are commonly used, and applies that knowledge when it writes SQL and investigates your data. Without it, Orion still connects, queries, and builds dashboards as normal. The collection reads job metadata only, never query results. To enable it, grant the BigQuery Service Account BigQuery Job User and BigQuery Resource Viewer on every project where the query jobs run. Granting Resource Viewer only on the project that stores the tables does not expose jobs billed through a different execution project. If you use per-user OAuth, these grants still go on the shared service account because scheduled collection is unattended. If Orion reports that usage intelligence needs additional access:

Grant the missing roles to the BigQuery Service Account shown in Orion.
In Orion, open the data source’s Refresh Data tab.
Select Full Resync to retry immediately. Orion will also retry during the next nightly refresh.

For a custom role, include bigquery.jobs.create and bigquery.jobs.listAll.

Per-user OAuth (optional)

By default, Orion queries BigQuery through the shared service account above. With per-user OAuth, Orion instead runs each person’s BigQuery queries under their own Google identity, so what each user can see in Orion follows the BigQuery permissions they already have, rather than a single shared service account.

Per-user OAuth builds on the service account setup above, so complete that first. The service account is still used for unattended work such as scheduled refreshes with no individual owner and schema introspection.

Use it when you want each person’s data access in Orion to match their existing BigQuery roles.

Create an OAuth client in Google Cloud

In APIs & Services → OAuth consent screen, set the User type to Internal so only your Google Workspace users can sign in
In APIs & Services → Credentials, click Create Credentials → OAuth client ID
Application type: Web application
Add the Authorized redirect URI provided by your Gravity contact. It points at Orion’s OAuth callback, for example https://g.runorion.com/datasource/bq-oauth/callback
Click Create, then copy the Client ID and Client Secret

Enter the OAuth client in Orion

On the BigQuery data source (Configuration → Data Sources), open the Connection tab, click Edit, and set:

Field	Value
Authentication Mode	Per-user OAuth
OAuth Client Reference	A short name for this client (e.g. `acme-bigquery`)
OAuth Client ID	From the previous step
OAuth Client Secret	From the previous step

Save. The client ID and secret are sent to Orion’s gateway and stored encrypted; they are never written to Orion’s database. To rotate the secret later, enter the new values and save again. Leave them blank to keep the current ones.

Each user connects their Google account

The first time someone opens a project that uses this data source, Orion prompts them to connect. They click Connect BigQuery, sign in with Google, and consent once. From then on their queries run under their own identity.

Each person must sign in with the Google account whose email matches their Orion sign-in. If your team signs in to Orion with Google (SSO), this matches automatically.

A couple of things to know:

Scheduled work runs as its creator. A metric or workflow that someone schedules runs under that person’s connected account. Work with no individual owner uses the service account.
If a user disconnects or loses BigQuery access, their scheduled work pauses until they reconnect. This is deliberate: Orion never falls back to broader access than the user has.

↑ Back to all data sources

Snowflake

Orion connects to Snowflake using key pair authentication. You create a dedicated service user, grant it read-only access to the data you want analyzed, and associate a public key with it. Orion holds the matching private key to authenticate. Connection information

Field	Description
Account	Your Snowflake account identifier (e.g. `orgname-account_name` → `orgname-account_name.snowflakecomputing.com`)
User / Role / Warehouse / Database / Schema	Standard connection context values used by Snowflake clients and drivers

Required grants (on the role you configure for the connection)

GRANT USAGE ON WAREHOUSE <w> TO ROLE <r>;
GRANT USAGE ON DATABASE <db> TO ROLE <r>;
GRANT USAGE ON SCHEMA <db>.<schema> TO ROLE <r>;
GRANT SELECT ON ALL TABLES IN SCHEMA <db>.<schema> TO ROLE <r>;
-- Optional, recommended: usage intelligence. See Snowflake usage intelligence permissions below.
GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE <r>;

Key pair authentication setup

Generate an encrypted key pair

Generate an encrypted private-public key pair (RSA 2048 or 3072 recommended).

# Encrypted private key (an optional passphrase is recommended)
openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 des3 -inform PEM -out rsa_key.p8
# Associated public key
openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

The private key stays on your system. The public key (rsa_key.pub) is added to the Snowflake user.

Create (or reuse) a service user

CREATE USER orion_svc
  DEFAULT_ROLE = <r>
  MUST_CHANGE_PASSWORD = FALSE;

Assign the relevant role with the grants listed above.

Associate the public key with the service user

ALTER USER orion_svc SET RSA_PUBLIC_KEY='<contents of rsa_key.pub>';

Enter the connection in Orion

In Orion, go to Configuration → Data Sources, click Add Data Source, and choose Snowflake. Enter the connection information from the table above (account, user, warehouse, role; database and schema are optional) and upload the private key file. Provide the passphrase if the key is encrypted.

Snowflake usage intelligence permissions

Usage intelligence is optional but recommended. With it, Orion reads Snowflake query metadata to learn which tables, columns, and joins your team uses most, and applies that knowledge when it writes SQL and investigates your data. Without it, Orion still connects, queries, and builds dashboards as normal. The collection reads query metadata only, never query results. The grant is the last line of the block above. Run it as a role that can grant Snowflake database roles, such as ACCOUNTADMIN. That database role gives Orion SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY and SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY. Query history records which statements ran. Access history records which objects and columns each statement touched. ACCESS_HISTORY requires Enterprise Edition or higher. On a lower edition the grant succeeds and the view stays unavailable, so Orion reads the query text instead and reports the reduced evidence in the data source’s usage status.

A connection test passes without this grant, because it does not read account usage. Your queries and dashboards keep working while usage intelligence stays unavailable.

Orion reports two different gaps here, and they take different fixes. Usage intelligence needs additional Snowflake access. Orion cannot read account query history. Grant SNOWFLAKE.GOVERNANCE_VIEWER to the role shown in Orion, open the data source’s Refresh Data tab, and select Full Resync. Usage intelligence found no tables to analyze. The role cannot read the configured database’s metadata, so Orion has nothing to attribute usage to. Grant usage on the database and schema, and select on its tables, then use Refresh Now on the same tab. Orion skips the collection in this state rather than failing the refresh. A large account can need more than one Full Resync to finish its first 90 days. Each run continues from the progress the last one saved, so partial coverage after one run is expected rather than a failure. Snowflake fills the Account Usage views on a delay, so Orion collects complete days that are at least four hours old. Activity from the last few hours appears in the next collection. What we store: Orion uses the private key to authenticate connections. We store the encrypted key and passphrases in our database, and we encrypt your encrypted key. See the Snowflake key pair documentation. ↑ Back to all data sources

Databricks

Orion connects to Databricks using a dedicated Service Principal and a SQL Warehouse for compute. We strongly recommend OAuth M2M authentication.

Create a Service Principal

We recommend a dedicated Service Principal for Orion. Follow the official documentation to create one.

Create credentials

OAuth M2M (recommended)

Follow the official documentation to create a Client ID and Client Secret. Copy the Client Secret immediately; you only get one chance to see it.

Personal Access Token (legacy)

Follow the official documentation. PATs are legacy and being phased out by Databricks, so prefer OAuth M2M.

Create or identify a SQL Warehouse

SQL Warehouses are the compute resources used to execute queries. Either identify an existing warehouse, or create a dedicated one following the official documentation. Make note of the warehouse’s HTTP Path.

Grant access

Assign the Service Principal to your workspace with the Databricks SQL access entitlement. Grant CAN USE on the SQL Warehouse.For business data queries, grant USE CATALOG, USE SCHEMA, and SELECT only on the catalogs, schemas, and tables Orion should query. Warehouse usage intelligence is optional but recommended, and needs the additional system-table grants below. Orion does not need admin, ownership, or write permissions.

Configure the connection in Orion

In Orion, go to Configuration → Data Sources, click Add Data Source, and choose Databricks. Give the connection a name and optional description, then fill in:

Field	Description	Example
Host	The host URL for your Databricks	`abc-123.cloud.databricks.com`
Warehouse HTTP Path	The HTTP path to your chosen SQL Warehouse	`/sql/1.0/warehouses/abc123`
Client ID & Client Secret	OAuth M2M credentials

Set Catalog and at least one Included schemas entry for usage intelligence. Enter schema names on separate lines or separate them with commas. New schemas are not added automatically.Use separate Orion data sources for separate catalogs or schema groups. Each schema should belong to one Orion data source within the workspace.

The scope also limits schema sync. Tables outside your selection may disappear from Orion and affect existing metrics or mappings. The scope does not change the Service Principal’s Databricks permissions.

Databricks usage intelligence permissions

Usage intelligence is optional but recommended. With it, Orion’s nightly job reads query history and lineage to learn which tables and columns your team uses, and applies that knowledge when it writes SQL and investigates your data. Without it, Orion still connects, queries, and builds dashboards as normal. Optional SQL-text access adds query patterns, filters, and explicit joins. This collection does not read business table rows or historical query results. Your workspace must support Unity Catalog, with the system.query and system.access tables available. The existing read grants provide metadata visibility for your selected business catalog and schemas. Usage collection does not need additional SELECT grants on business tables. Ask an administrator authorized to grant access to these objects to run the following SQL. Replace ORION_SERVICE_PRINCIPAL_APPLICATION_ID with your Service Principal’s application ID, keeping the backticks.

GRANT USE CATALOG ON CATALOG system TO `ORION_SERVICE_PRINCIPAL_APPLICATION_ID`;
GRANT USE SCHEMA ON SCHEMA system.query TO `ORION_SERVICE_PRINCIPAL_APPLICATION_ID`;
GRANT USE SCHEMA ON SCHEMA system.access TO `ORION_SERVICE_PRINCIPAL_APPLICATION_ID`;
GRANT SELECT ON TABLE system.query.history TO `ORION_SERVICE_PRINCIPAL_APPLICATION_ID`;
GRANT SELECT ON TABLE system.access.table_lineage TO `ORION_SERVICE_PRINCIPAL_APPLICATION_ID`;
GRANT SELECT ON TABLE system.access.column_lineage TO `ORION_SERVICE_PRINCIPAL_APPLICATION_ID`;

System table	What Orion uses it for
`system.query.history`	Query activity, status, timing, and available SQL text
`system.access.table_lineage`	Evidence of which tables a query reads or writes
`system.access.column_lineage`	Evidence of which columns a query touches

USE CATALOG and USE SCHEMA allow access to the containing namespaces. SELECT allows reads of only the three named system tables. These grants do not include billing tables, audit logs, or write access. See Databricks system-table access.

These tables can expose activity across your account’s workspaces in the same region. Orion limits collection to the connected workspace and attributes object usage to the selected catalog and schemas. These application filters do not narrow the underlying Databricks grants. Review this access with your security team before approval.

Optional access to SQL text

For SQL-derived query patterns and joins, ask an account administrator to add Orion’s Service Principal to the account-level databricks_pii_access group. The name is case-sensitive. If the group does not exist, the account administrator must create it through the account console or identity provider. This membership allows unmasked query text on supported Databricks surfaces where the principal also has access. SQL text can contain sensitive literals, such as names or email addresses. Membership does not replace the system-table grants above, and Orion does not need an account admin role. See Databricks group setup. Orion processes readable SQL during collection and stores derived usage evidence with literal values removed. The warehouse-usage workflow does not persist raw SQL or query parameter values in Redis or cloud storage. If you decline this access and Databricks redacts SQL text, Orion still publishes a usage summary when readable lineage provides table evidence:

Available evidence	What Orion can include
Table and column lineage	Observed usage counts, table rankings, and last-used times
Readable, supported SQL text	Additional query patterns, filter shapes, and explicit join keys
Redacted SQL text	No SQL-derived enrichment for those statements

The cached summary records coverage limits because lineage may miss queries or columns. Tables used together do not prove an explicit SQL join. If lineage is also unavailable, Orion cannot attribute usage to tables from redacted statements.

Removing group membership later does not erase earlier usage summaries. Previously collected data can remain in cloud storage and the cache. Orion can retain a higher-quality cached snapshot when a later scan has less coverage. Contact Gravity if you need previously collected data removed.

Verify usage access

Verify access with the same Service Principal Orion uses. A successful connection test does not prove access to query history, lineage, or unmasked SQL text. After the grants take effect, open the data source’s Refresh Data tab and select Full Resync. Review the usage status for missing permissions and coverage limits. Existing connections without a scope must first set Catalog and Included schemas. Open the Connection tab, click Edit, fill both fields, then save. The first collection builds up to 90 complete UTC days of history. Later runs reuse saved history and refresh the newest two days, with at least two hours for system tables to settle. Large workspaces may need multiple runs to complete the initial history. If SQL text stays unavailable after group membership changes, ask your administrator to check encryption settings. Workspaces with customer-managed keys may need additional system-catalog configuration. ↑ Back to all data sources

Looker

Orion connects to Looker using a dedicated user account with analyst-level (read-only) permissions plus API credentials. You’ll also grant the account access to the Spaces (folders) that hold your dashboards and Looks. Standard deployment: We request a Looker account for the email orion@gravity.foundation, with permissions matching those of a typical analyst at your organization. Orion only needs read access. Required permissions (in addition to analyst-level access)

Models (docs): can be scoped to necessary models via model sets; includes the explore permission
see_system_activity, see_lookml, see_sql
see_user_dashboards (or provide PDFs of sample dashboards instead)
create_custom_fields: enables building custom fields via + Add
login_special_email: only if using non-email (third-party) authentication

Content access (Spaces / folders) Model permissions and content access are configured separately in Looker. The Orion user also needs view access to the Spaces where your dashboards and Looks are stored:

Open the folder

Navigate to the folder(s) containing your key dashboards.

Manage access

Click Manage Access on the folder.

Add the Orion user

Add the Orion user (or a group it belongs to) with View access.

Without this step, the Orion user will have model and query permissions but won’t be able to see any saved dashboard content. See Managing access to folders.

API credentials: Generate API keys for orion@gravity.foundation (docs). Then, in Orion, go to Configuration → Data Sources, click Add Data Source, choose Looker, and enter your Looker base URL, the client_id, and the client_secret. Third-party authentication: If you use Okta or another third-party provider, add the login_special_email permission. Navigate to the Roles section of the Admin panel (https://[organization].cloud.looker.com/admin/roles) and, if you don’t already have external users, create a new permission set. See the Looker documentation.

LookML augmentation (optional)

Beyond querying dashboards and Looks, Orion can read your LookML business logic directly from its GitHub repository, reusing the dimensions, measures, and joins you have already defined to write better SQL. Setup takes about 10 minutes and needs a GitHub repository admin for one step.

The GitHub account that owns the token you create must have Read access to the LookML repository (see Step 9). A valid token from an account without repo access fails with a “repository not found” error. If you are not a repo admin, loop one in for Step 9.

Open the Looker datasource

On the Configuration → Data Sources page, open the Looker datasource and select the Augmentation tab.

The Coffee Rush Looker datasource in Orion Configuration, with the Connection, Refresh Data, Augmentation, Schema, and Migration tabs — Open the Looker Augmentation tab

Start token creation

Click the Create token link to open GitHub.

The Create token link beneath the Personal Access Token field on the Augmentation tab — Start creating a GitHub token

Create a fine-grained PAT

On GitHub, begin creating a fine-grained personal access token.

GitHub's fine-grained personal access tokens page with the Generate new token button — Create a fine-grained GitHub token

Set the resource owner and expiration

Resource owner: select the organization or account where the Looker GitHub repository lives.
Expiration (TTL): set the token expiration. We recommend the longest your security policy allows; GitHub’s maximum for fine-grained tokens is 1 year (366 days).

The new fine-grained token form with token name, resource owner, and expiration fields — Set the token owner and expiration

When this token expires, Orion can no longer pull your LookML repo. Schema sync and the nightly enrichment that reads your LookML will fail with an authentication error, and any insights that depend on that business logic go stale until you issue a new token and update the connection. Set a reminder to rotate the token before it expires.

Select the repository

Choose the Looker repository from the dropdown.

Set permissions

Grant read-only access, nothing more:

Contents: Read-only
Metadata: Read-only

Repository access set to the LookML repo, with Contents and Metadata permissions set to Read-only — Grant the token read-only repository access

Create the token

Generate the token and copy it. You will not be able to view it again.

Save the configuration

Back in Orion, enter the repository URL, the PAT, and the rest of the configuration (see the Augmentation tab in Step 2), then save.

Grant the token's account access to the repository

The account that owns the token must have at least Read access to the LookML repo, or Orion authenticates but cannot see the repo and the connection fails with “repository not found.”A repository admin:

In GitHub, open the LookML repository → Settings → Collaborators and teams (under Access).
Under Manage access, click Add people (or Add teams if you manage access by team).
Enter the username of the account tied to the token, or the service account created for Orion.
Set the role to Read. No write or admin access is required.
Send the invitation.
The account owner accepts the invite. Until they do, access does not take effect and the connection will still fail.
Return to the Orion connection and reconnect.

The LookML repository's Collaborators and teams page in GitHub, under Settings, with the Add people option — Give the token owner access to the LookML repository

Use a shared service account rather than an individual’s personal account. If a person leaves or loses access, a personal-account token breaks the connection.

Test the connection

On the Augmentation tab, click Test Connection. This verifies that Orion can reach the repository with the token and branch you configured, without running a full sync.

Success: the connection is valid. Orion can authenticate and see the repo. Click Sync Now to pull the LookML files. When it finishes, Status shows Synced, along with the file count and the latest commit.
Failure: read the error message:
- “Repository or branch not found” usually means the token’s account lacks Read access to the repo (revisit Step 9), or the branch name is wrong. Leave Branch blank to use the repo default, or enter the correct branch.
- “Authentication failed” means the token is invalid or expired. Generate a new one (Steps 3-7) and re-enter it.
- “Access forbidden” means the token is missing a permission or, if your org enforces SSO, has not been SSO-authorized for the organization.

Once the test passes and the first sync completes, Orion is reading your LookML.

Migrating dashboards into Orion (optional)

LookML augmentation teaches Orion the business logic behind your models. Migration ports the dashboards themselves into Orion projects, each with its own metrics and workflows. The two are independent, and either one runs on its own.

The Migration tab appears on Looker data sources only, and only administrators can start or roll back a migration.

Before you start: Orion extracts the SQL behind your dashboards and runs it against a database data source, the Target Database. The target must be the same database your Looker connection queries. Connect that data source first. Snowflake, BigQuery, Postgres, and Databricks connections qualify.

Open the Migration tab

Go to Configuration → Data Sources, open the Looker data source, and select the Migration tab. Then click Migrate to Orion.

The Looker data source page with the Migration tab selected among Connection, Refresh Data, Augmentation, Schema, and Migration. Under Available, a Migrate to Orion card describes porting Looker dashboards into Orion projects — Start a Looker migration

Pick the Target Database

Choose the Target Database, then click Choose Dashboards. The button stays disabled until a target is set and Looker reads as Connected.

Select the dashboards

Orion reads your Looker usage history, proposes dashboards to migrate, and groups them into projects. Each card shows the title, tile count, user count, and query count. Every dashboard starts selected: clear what you do not want, and confirm the selection.Paste a Looker dashboard URL into Add Dashboard by URL to include one the list missed.

The Select Dashboards to Migrate step on the Looker Migration screen. A Corporate Finance and Cash Flow project group holds one selected dashboard with tile, user, and query counts, above Add Dashboard by URL and a Migrate 1 Dashboard button — Select Looker dashboards to migrate

The status view updates itself while the run works, so you can leave and come back. The summary then counts the projects, metrics, and workflows created and links to each one. Dashboards Orion could not port appear under Excluded Dashboards, each with a reason.

Rollback Migration deletes every project and resource the run created. That cannot be undone. Start New Migration clears the record instead and leaves the created projects in place.

A data source runs one migration at a time. Start the next one once the current run has completed or failed. ↑ Back to all data sources

PostgreSQL

Orion connects to PostgreSQL with username/password authentication. Create a dedicated read-only user and grant it SELECT on the schemas and tables you want analyzed. Connection information

Field	Description
Host	PostgreSQL server hostname / IP address
Port	PostgreSQL server port (default: `5432`)
Database	Target database name
User	PostgreSQL username for authentication
Password	User password for authentication
SSL Mode	`disable` / `allow` / `prefer` / `require` / `verify-ca` / `verify-full`

Required grants

GRANT CONNECT ON DATABASE <db> TO <user>;
GRANT USAGE ON SCHEMA <schema> TO <user>;
GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO <user>;
-- So future tables are visible automatically:
ALTER DEFAULT PRIVILEGES IN SCHEMA <schema> GRANT SELECT ON TABLES TO <user>;

Setup

Create the service user

CREATE USER orion_svc WITH PASSWORD '<secure_password>';

Configure PostgreSQL for connections

In postgresql.conf: set listen_addresses = '*' so PostgreSQL accepts connections, and ssl = on for SSL connections.

Configure client authentication

In pg_hba.conf:

host    <database> orion_svc <ip_range> md5
hostssl <database> orion_svc <ip_range> md5   # SSL-only

Restart and grant

Restart the PostgreSQL service, then assign the grants listed above to the service user.

Enter the connection in Orion

In Orion, go to Configuration → Data Sources, click Add Data Source, and choose Postgres. Enter the connection information from the table above (host, port, database, user, password, SSL mode).

What we store: username/password authentication; we encrypt your plain-text password in our database. See the PostgreSQL docs on connection parameters, access control, and client authentication. ↑ Back to all data sources

MySQL

Orion connects to MySQL with username/password authentication. Create a dedicated user and grant it read-only access to the target database. Connection information

Field	Description
Host	MySQL server hostname / IP address
Port	MySQL server port (default: `3306`)
Database	Target database (schema) name
User	MySQL username for authentication
Password	User password for authentication
SSL Mode	`disabled` / `preferred` / `required` / `verify-ca` / `verify-identity`
SSL CA Certificate (optional)	PEM-encoded CA bundle, required for `verify-ca` / `verify-identity` when the server certificate is not signed by a publicly trusted CA

In MySQL, a “database” and a “schema” are the same thing. The Database value above is the schema Orion will read from.

Required grants

-- Read-only access to all current and future tables/views in <db>
GRANT SELECT, SHOW VIEW ON <db>.* TO '<user>'@'<host_or_%>';
FLUSH PRIVILEGES;

Setup

Create the service user

CREATE USER 'orion_svc'@'<host_or_%>' IDENTIFIED BY '<secure_password>';

Replace <host_or_%> with the IP/CIDR Orion will connect from (e.g. 'orion_svc'@'10.0.0.0/8'), or use '%' to allow any source.

Configure MySQL for connections

Ensure MySQL accepts remote connections in my.cnf (or mysqld.cnf):

[mysqld]
bind-address = 0.0.0.0
# For SSL:
require_secure_transport = ON
ssl-ca   = /path/to/ca.pem
ssl-cert = /path/to/server-cert.pem
ssl-key  = /path/to/server-key.pem

Optionally require SSL for this user only: ALTER USER 'orion_svc'@'<host_or_%>' REQUIRE SSL;

Restart and grant

Restart the MySQL service, then assign the grants listed above to the service user.

Enter the connection in Orion

In Orion, go to Configuration → Data Sources, click Add Data Source, and choose MySQL. Enter the connection information from the table above (host, port, database, user, password, SSL mode, and the CA certificate if applicable).

What we store: username/password authentication; we encrypt your plain-text password at rest. If you provide an SSL CA certificate, we encrypt the PEM contents alongside it. See the MySQL docs on access control and encrypted connections. ↑ Back to all data sources

Redshift

Orion connects to Amazon Redshift (cluster or Serverless workgroup) over the standard PostgreSQL wire protocol (port 5439) using username/password authentication. Orion only ever issues read (SELECT) queries. Connection details

Field	Description
Host	Your cluster endpoint, e.g. `my-cluster.abc123xyz.us-east-1.redshift.amazonaws.com`. For Serverless: `my-workgroup.123456789012.us-east-1.redshift-serverless.amazonaws.com`
Port	Defaults to `5439`
Database	The database name to connect to, e.g. `analytics` or `dev`
User	The read-only user created for Orion (we suggest `orion`)
Password	The password for that user
SSL Mode	`require` (default; Redshift clusters always terminate TLS)

Database user & permissions

On Redshift, a user can only see a table in information_schema if it has been granted access, so these grants also determine what Orion can discover.

CREATE USER orion PASSWORD '<choose-a-strong-password>';
-- For each schema you want Orion to access:
GRANT USAGE ON SCHEMA <schema_name> TO orion;
GRANT SELECT ON ALL TABLES IN SCHEMA <schema_name> TO orion;
-- So future tables are visible automatically:
ALTER DEFAULT PRIVILEGES IN SCHEMA <schema_name> GRANT SELECT ON TABLES TO orion;

Orion does not need INSERT / UPDATE / DELETE / CREATE, so please do not grant write access.

Network access: Orion connects from our infrastructure, so the endpoint must be reachable on the Redshift port. Allow inbound traffic on port 5439 from Orion’s egress IP range in the cluster’s VPC security group. See the docs on managing Redshift security groups. Enter the connection in Orion: go to Configuration → Data Sources, click Add Data Source, choose Amazon Redshift, and enter the connection details from the table above. ↑ Back to all data sources

Amazon Athena

Orion connects to Amazon Athena to run serverless SQL over data in S3. Table and column metadata comes from your AWS Glue Data Catalog; queries run through Athena and write their results to an S3 output location you control. Orion only ever issues read (SELECT) queries against your tables. Authentication uses an IAM access key for a dedicated user. You create the user, attach a least-privilege policy, and enter the access key ID and secret in Orion.

Every Athena query must write its results somewhere in S3. This is an Athena requirement, not an Orion one: the output location (or a workgroup that enforces one) is where Athena stages query output before Orion reads it. The IAM user therefore needs write access to that one output prefix, even though it only reads your actual data.

Connection details

Field	Description	Example
AWS Access Key ID	Access key ID for the dedicated IAM user	`AKIA...`
AWS Secret Access Key	Secret access key for that user	(sensitive)
Region	AWS region where Athena and your Glue catalog live	`us-east-1`
S3 Output Location	S3 URI where Athena stages query results (must end in `/`)	`s3://my-bucket/athena-results/`
Workgroup	Athena workgroup to run queries under (defaults to `primary`)	`primary`
Data Catalog	Athena data catalog name (defaults to `AwsDataCatalog`)	`AwsDataCatalog`
Database (optional)	Scope schema exploration to a single Glue database	`analytics`

If you grant the optional query-history permissions below, Orion reads the chosen workgroup’s query history to learn which tables and columns your team queries most. That history includes the SQL text of every query run in the workgroup. Use a dedicated workgroup if it may contain sensitive queries.

IAM setup

Create a dedicated IAM user

In the AWS IAM console, create a user for Orion (we suggest orion-athena) with programmatic access, then create an access key for it. Copy the Access Key ID and Secret Access Key; the secret is only shown once.

Attach a least-privilege policy

Attach a policy for one Athena workgroup, one Glue database, the S3 prefix holding your data, and the S3 prefix for query results. Replace the placeholders with your AWS account, region, workgroup, database, bucket, and prefix values. Prefix values should not start or end with /. Ask your Gravity contact for Orion’s egress IPs if you use the final, optional deny statement.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AthenaQuery",
      "Effect": "Allow",
      "Action": [
        "athena:StartQueryExecution",
        "athena:StopQueryExecution",
        "athena:GetQueryExecution",
        "athena:GetQueryResults",
        "athena:GetWorkGroup"
      ],
      "Resource": "arn:aws:athena:<REGION>:<ACCOUNT_ID>:workgroup/<WORKGROUP>"
    },
    {
      "Sid": "AthenaUsageHistory",
      "Effect": "Allow",
      "Action": [
        "athena:ListQueryExecutions",
        "athena:BatchGetQueryExecution",
        "athena:GetQueryRuntimeStatistics"
      ],
      "Resource": "arn:aws:athena:<REGION>:<ACCOUNT_ID>:workgroup/<WORKGROUP>"
    },
    {
      "Sid": "GlueCatalogRead",
      "Effect": "Allow",
      "Action": [
        "glue:GetDatabase",
        "glue:GetTable",
        "glue:GetTables",
        "glue:GetPartitions"
      ],
      "Resource": [
        "arn:aws:glue:<REGION>:<ACCOUNT_ID>:catalog",
        "arn:aws:glue:<REGION>:<ACCOUNT_ID>:database/<DATABASE>",
        "arn:aws:glue:<REGION>:<ACCOUNT_ID>:table/<DATABASE>/*"
      ]
    },
    {
      "Sid": "S3BucketLocation",
      "Effect": "Allow",
      "Action": "s3:GetBucketLocation",
      "Resource": [
        "arn:aws:s3:::<DATA_BUCKET>",
        "arn:aws:s3:::<RESULTS_BUCKET>"
      ]
    },
    {
      "Sid": "S3ListData",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::<DATA_BUCKET>",
      "Condition": {
        "StringLike": { "s3:prefix": ["<DATA_PREFIX>/", "<DATA_PREFIX>/*"] }
      }
    },
    {
      "Sid": "S3ReadData",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::<DATA_BUCKET>/<DATA_PREFIX>/*"
    },
    {
      "Sid": "S3ListResults",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::<RESULTS_BUCKET>",
      "Condition": {
        "StringLike": { "s3:prefix": ["<RESULTS_PREFIX>/", "<RESULTS_PREFIX>/*"] }
      }
    },
    {
      "Sid": "S3ReadWriteResults",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:AbortMultipartUpload"],
      "Resource": "arn:aws:s3:::<RESULTS_BUCKET>/<RESULTS_PREFIX>/*"
    },
    {
      "Sid": "DenyOutsideOrionEgress",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": ["<ORION_EGRESS_IP_1>/32", "<ORION_EGRESS_IP_2>/32"]
        },
        "Bool": { "aws:ViaAWSService": "false" }
      }
    }
  ]
}

Set Database in Orion to the database named in the policy. Orion then reads that database without listing the whole catalog.AthenaUsageHistory is optional. Remove that statement if you do not want Orion to read the workgroup’s query history. DenyOutsideOrionEgress is also optional; remove it if you do not want to restrict direct use of the access key to Orion’s egress IPs.

Keep aws:ViaAWSService in the condition. Athena accesses other AWS services on your behalf, and those requests do not originate from Orion’s IPs. AWS cautions against source-IP denies on S3 actions used by Athena. Test a query with the pilot workgroup and buckets before using this deny in production.

Orion tenants share these egress IPs. The IP condition does not identify a tenant; the dedicated access key and its permissions control access to your resources.

Confirm the workgroup and output location

Make sure the workgroup you name exists in the chosen region, and that either the workgroup enforces an output location or the S3 Output Location you enter is writable by the IAM user. If the workgroup enforces its own output location, that setting wins over the value you enter in Orion.

Enter the connection in Orion

In Orion, go to Configuration → Data Sources, click Add Data Source, and choose Amazon Athena. Enter the connection details from the table above. Use the Workgroup and Database named in the policy. Leave Data Catalog at AwsDataCatalog.

Network access: Orion reaches Athena and Glue over public AWS API endpoints, so the connection needs no VPC allowlist. Athena accesses S3 from AWS, not from Orion’s egress IPs. If your bucket policies restrict source IPs or VPC endpoints, account for Athena’s S3 access when configuring them. The optional deny statement above restricts direct use of the access key by source IP. What we store: the IAM access key ID and secret access key, encrypted at rest in our database. To rotate the key later, open the data source’s Connection tab, click Edit, enter the new values, and save. Leave the secret blank to keep the current one. Known limitations

IAM access key only. Cross-account IAM role assumption is a planned fast-follow; today the connection uses a long-lived access key, so rotate it on your normal cadence.
Output location is mandatory. Athena cannot run a query without a place to write results, so the workgroup must enforce one or you must supply the S3 Output Location.
dbt enrichment is supported on Athena connections (see dbt); semantic enrichment from a Looker connection can also be projected onto Athena schemas.

↑ Back to all data sources

Microsoft Fabric

Orion connects to a Microsoft Fabric Warehouse using a Service Principal (App Registration) in your Microsoft Entra ID tenant. Orion connects over TDS (the SQL endpoint) using ODBC Driver 18 with Service Principal authentication, with no interactive login required. Azure App Registration

Create an App Registration in your Entra ID tenant (docs)
Note the Application (client) ID and Directory (tenant) ID
Create a Client Secret under Certificates & secrets (docs) and note the secret value (not the Secret ID). Recommended expiry: 12 months

Fabric Admin Portal settings (must be enabled by a Fabric Administrator)

Navigate to Fabric Admin Portal → Tenant settings → Developer settings
Enable Service principals can use Fabric APIs
Scope to a security group containing the Orion Service Principal (recommended), or enable for the entire organization

Workspace access: Open the workspace containing your Warehouse, click Manage access → Add people or groups, search for the App Registration name, and assign the Viewer role (minimum). Contributor is recommended for full metadata access. Warehouse SQL endpoint: Open the Warehouse in Fabric, click Settings → SQL connection string. The hostname looks like xxxxxxxx.datawarehouse.fabric.microsoft.com. Note the Database name (the Warehouse name). Credentials summary

Field	Description	Example
Server Hostname	SQL connection string from Warehouse settings	`xyz.datawarehouse.fabric.microsoft.com`
Database	Warehouse name	`my-warehouse`
Tenant ID	Entra ID Directory (tenant) ID	`xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`
Client ID	App Registration Application (client) ID	`xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`
Client Secret	App Registration client secret value	(sensitive)

Enter the connection in Orion: go to Configuration → Data Sources, click Add Data Source, choose Microsoft Fabric Warehouse, and enter the credentials from the table above.

Orion uses read-only SQL (SELECT only) to discover your schema via INFORMATION_SCHEMA, run agent-generated queries, and stream results into its analysis pipeline. It never executes DDL, DML, or stored procedures. If you use dbt with Fabric, Orion can enrich metadata with dbt models and lineage; see dbt.

↑ Back to all data sources

Delta Lake

Orion connects to Delta Lake tables on Azure Data Lake Storage Gen2 (abfss://) or Google Cloud Storage (gs://). Orion reads the Delta table directly via its transaction log. There is no warehouse, cluster, or notebook to provision. You provide two things: the Delta table or table root URI, and credentials with read access to that location. The URI points at a Delta table folder, or at a parent folder holding many Delta tables. Set Object storage to the provider that holds them: Orion refuses a URI whose scheme does not match that selection.

Orion only performs read-only scans against your storage account / bucket: no writes, no vacuums, no schema changes.

Azure Data Lake Storage Gen2
Google Cloud Storage

Storage account access

The Table URI looks like abfss://<container>@<storage-account>.dfs.core.windows.net/<path>
<path> can point to a single Delta table folder (containing a _delta_log/ subdirectory) or a parent folder; in the parent case, Orion exposes every Delta table found underneath
Confirm hierarchical namespace is enabled on the storage account (required for abfss://)

Credentials (pick one)

SAS token (preferred)

Read-only and time-bounded (docs). Scope to the container, permissions read + list (sp=rl), expiry 90 days or longer. Send the token query string (with or without a leading ?).

Account key

Read/write, full access, only if SAS is not viable. Either the raw account key, or the full connection string.

What you enter in Orion (under Configuration → Data Sources → Add Data Source → Delta Lake): the full abfss://... URI, the Azure storage account name, and your credential. Storage authentication is where you pick SAS token or Account key. The account name is required with either one.

Bucket access

The Table URI looks like gs://<bucket>/<path>
As with Azure, <path> can be a single Delta table folder or a parent folder containing many Delta tables

Credentials (pick one)

HMAC key & secret

Create HMAC keys for a service account that has roles/storage.objectViewer (or finer-grained access) on the target bucket.

Workspace identity

No secret to share. Grant the Orion workload identity your contact provides roles/storage.objectViewer on the bucket.

What you enter in Orion (under Configuration → Data Sources → Add Data Source → Delta Lake): the full gs://... URI, and your choice in Google Cloud credentials. HMAC key asks for an HMAC access key ID and an HMAC secret. Workspace identity asks for neither: confirm with your Gravity contact that it is configured.

Parent-folder mode: point the Table URI at a parent directory (e.g. abfss://.../silver/) and Orion discovers every Delta table underneath on schema sync. Partition columns need no setup; Orion reads them from the Delta log for query pruning automatically.

↑ Back to all data sources

MotherDuck

Orion connects to MotherDuck using access token authentication. You create an access token in your MotherDuck account, and Orion uses it to run read-only (SELECT) queries against a single database. There is no service user, warehouse, or cluster to configure. Connection information

Field	Description
MotherDuck Token	Access token created in MotherDuck under Settings → Access Tokens
Database	The database Orion queries: the bare name, without the `md:` prefix

Setup

Create an access token

In MotherDuck, go to Settings → Access Tokens
Create a token. A Read Scaling token is recommended
Copy the token

The token is a JWT: one long three-part string, like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoi....

A Read Scaling token is read-only on MotherDuck’s side and spreads Orion’s queries across replicas. Replicas are eventually consistent, so a result can trail the latest writes by a few minutes.

Enter the connection in Orion

In Orion, go to Configuration → Data Sources, click Add Data Source, and choose MotherDuck. Paste the token and enter the database name.

Enter the bare database name (analytics), not the md:analytics form a MotherDuck connection string uses. Names accept letters, digits, underscores, and hyphens, up to 128 characters, starting with a letter, digit, or underscore.

On connect, Orion discovers every table, view, and column in the database you named.

A database holding more than 5,000 tables and views is refused rather than trimmed, because a partial schema looks complete to everything downstream.

Set comments on your MotherDuck tables and columns. Orion reads them and shows them as descriptions on the Schema tab.

What we store: the MotherDuck token, encrypted at rest in our database. To rotate it, open the data source’s Connection tab, click Edit, enter the new token, and save. Leave the field blank to keep the current token. dbt enrichment is supported on MotherDuck connections: see dbt. ↑ Back to all data sources

dbt

Orion connects to dbt to enrich a warehouse connection with your dbt model descriptions and lineage. dbt is not a data source of its own: you attach a dbt project to a warehouse connection you have already set up. Pick the dbt Source Type by where your project’s metadata lives. Choose dbt Cloud if your production jobs run in dbt Cloud. Choose GitHub Repository if you run dbt Core from a GitHub repository. Choose Upload manifest.json if Orion cannot reach either, because then you supply the file yourself.

In Orion, go to Configuration → Data Sources
Click the data source tile you want to enrich, then select the Augmentation tab
On the dbt project card, open Add a dbt project
Set dbt Source Type, then follow the matching tab below

The Augmentation tab of a data source, selected among Connection, Refresh Data and Schema. Below it, the dbt project card explains what a dbt project adds, and its Add a dbt project row is outlined in red — Connect a dbt project to a data source

dbt Cloud
GitHub Repository
Upload manifest.json

Orion reads manifest.json from the latest successful run in the dbt Cloud environment you name. It fetches the file through the dbt Administrative API, so the token needs read access to jobs and runs. The environment needs at least one successful run before Orion can sync.Create the tokenCreate a dbt Cloud service token with a permission set that can read jobs and runs, such as Job Viewer or Read-Only. Give it access to the project you are connecting. A personal access token also works, with the access of the user who owns it.

A Metadata Only service token does not work. dbt limits it to the Discovery API, and Orion downloads run artifacts through the Administrative API, so every refresh fails.

Fill in the form

Field	What to enter
Account ID	Your dbt Cloud account ID. It is the number after `/deploy/` in the address of any dbt Cloud page.
API Token	The token you created above.
Project ID	Optional. Orion finds the run from the environment ID alone.
Environment ID	The deployment environment your production job runs in. Open that environment in dbt Cloud: its ID is the number after `/environments/` in the address.
Access URL (Optional)	Leave blank if you sign in at `cloud.getdbt.com`. Otherwise paste the access URL from Account settings → Account information in dbt Cloud, such as `abc123.us1.dbt.com`.

Then click Connect dbt Project.The environment ID is not the project ID, even though dbt shows both in the same address.Orion accepts the access URL with or without https:// and a trailing slash. It must be a dbt host under getdbt.com or dbt.com. If you change the access URL later, enter the API token again: Orion does not send a saved token to a new host.

Orion reads the .sql and .yml files in your dbt project straight from GitHub, on the latest commit of the branch you name. It does not run dbt. You connect it with a read-only fine-grained access token.Create a GitHub Personal Access Token

Navigate to Settings → Developer Settings → Personal access tokens → Fine-grained tokens
Click Generate new token
Set your organization as the resource owner (if required)
Configure permissions: Contents → Read access (Metadata is auto-added)
Under Repository access, select Only select repositories and add your dbt project repo only
Click Generate token, then copy and save it immediately: it will not be shown again

Fill in the form

Field	What to enter
Repository URL	The repository address on `github.com`, such as `https://github.com/acme/dbt-project`. A `.git` ending is fine.
Personal Access Token	The token you created above.
Branch (Optional)	The branch Orion reads. Leave blank for `main`. Use the branch your production dbt runs from.
Project Path (Optional)	The folder that holds `dbt_project.yml`, from the repository root. Leave blank when it sits at the root.
Models Path (Optional)	The models folder, relative to Project Path. Leave blank for `models`. Orion reads every `.sql`, `.yml` and `.yaml` file beneath it.

Then click Connect dbt Project.

Make sure there is no trailing slash at the end of the Repository URL.

Standard dbt projects only require two fields, Repository URL and Personal Access Token. Fill in the paths only when your dbt project lives in a subfolder of the repository.

Orion parses a manifest.json file you upload. Choose this when Orion cannot reach your dbt Cloud account or your repository. dbt writes the file to your project’s target/ directory each time it parses the project, for example on dbt compile or dbt build.Click Select File and choose the file. It must be valid JSON and smaller than 50 MB. The upload connects the project on its own, so there is no Connect dbt Project step, and a message reports how many models Orion parsed.If the data source already has a dbt project of another type, save the switch to Upload manifest.json first. The upload control appears once the change is saved.Orion reads only the file you uploaded, so upload a new one when your models change.

Once connected, the card shows the sync status, the model count, and when it last refreshed, next to a Refresh button. A failed refresh shows Sync failed on the card, with the reason underneath. To change the configuration later, open dbt project settings, click Edit, and the footer offers Save Changes and Disconnect. ↑ Back to all data sources

News API

Orion can search news headlines and fold them into an analysis as a dataset, useful for explaining external context behind a change in your numbers (“did coverage spike the week signups jumped?”).

Get a NewsAPI.org key

Add the connection

In Orion, go to Configuration → Data Sources and click Add Data Source
Select News API
Enter the key in NewsAPI.org API Key and click Connect Data Source

Enable News API on a project like any other data source, and users there can ask Orion to pull articles by keyword from the last 1 to 30 days. Results come back with date, title, source, and summary, as a dataset the analysis can correlate against your own data.

News API is a single tenant-wide connection; once added, the tile shows Already connected.

↑ Back to all data sources

Weather

The Weather source pulls daily weather from Open-Meteo. No account or API key is needed: add it from Configuration → Data Sources → Add Data Source → Weather and click Connect Data Source. Enable it on a project and users can ask for weather by location and date range: historical actuals back to 1940 and forecasts up to about 16 days out, with conditions, high and low temperatures, and precipitation. The data lands as a dataset the analysis can join against your business data, which is what you want for questions like “do cancellations track with bad weather?” ↑ Back to all data sources

​How Orion connects

Read-only

Least privilege

Encrypted at rest

​Choose your data source

BigQuery

Snowflake

Databricks

Looker

PostgreSQL

MySQL

Redshift

Amazon Athena

Microsoft Fabric

Delta Lake

MotherDuck

dbt

News API

Weather

​BigQuery

​Querying datasets in another project

​Usage intelligence permissions

​Per-user OAuth (optional)

​Snowflake

​Snowflake usage intelligence permissions

​Databricks

OAuth M2M (recommended)

Personal Access Token (legacy)

​Databricks usage intelligence permissions

​Optional access to SQL text

​Verify usage access

​Looker

​LookML augmentation (optional)

​Migrating dashboards into Orion (optional)

​PostgreSQL

​MySQL

​Redshift

​Amazon Athena

​Microsoft Fabric

​Delta Lake

SAS token (preferred)

Account key

HMAC key & secret

Workspace identity

​MotherDuck

​dbt

​News API

​Weather

How Orion connects

Choose your data source

BigQuery

Querying datasets in another project

Usage intelligence permissions

Per-user OAuth (optional)

Snowflake

Snowflake usage intelligence permissions

Databricks

Databricks usage intelligence permissions

Optional access to SQL text

Verify usage access

Looker

LookML augmentation (optional)

Migrating dashboards into Orion (optional)

PostgreSQL

MySQL

Redshift

Amazon Athena

Microsoft Fabric

Delta Lake

MotherDuck

dbt

News API

Weather