Connections & the credential vault | ATX AnalyticsTable Handbook

Connections & the credential vaultDefine a source once. Never put a password in a project file. Data sources are defined once and reused everywhere: local DuckDB and SQLite files, PostgreSQL, Microsoft SQL Server, Oracle, Google BigQuery, Snowflake, Databricks, Amazon Redshift, Microsoft Fabric / Azure Synapse and MySQL / MariaDB, plus cloud storage locations (Azure Blob, Google Cloud Storage and S3-compatible object stores) for imports, exports and backups. The rule that matters commercially is that credentials never live in the project file. They go into a local encrypted vault, so a project can be shared, e-mailed or committed to a repository without leaking a single password.

What it does

Relational and warehouse connectors: DuckDB, SQLite, PostgreSQL, SQL Server, Oracle (thin mode), Google BigQuery, Snowflake, Databricks, Amazon Redshift, Microsoft Fabric / Azure Synapse and MySQL / MariaDB — each available for import (Get Data → Databases), export (Export → Databases), SQL, pipelines and dashboards
Sign-in methods that store no secret where the platform has one: Snowflake key pair, Entra ID External OAuth, OAuth client credentials and workload identity; Databricks through an OAuth machine-to-machine service principal or, on Azure, a managed identity; Fabric and Synapse through an Entra ID service principal or managed identity; Redshift through an IAM role from the machine; BigQuery through application default credentials
Snowflake on AWS, Azure or Google Cloud addressed by its account identifier, with the detected cloud and region shown and private connectivity (PrivateLink, Private Link, Private Service Connect) one tick away
Queries that run as the signed-in person — for the warehouse's own row-level security and per-user audit — when the app is signed in with Entra ID and the connection uses on-behalf-of; Redshift and BigQuery run as the connection
Cloud object storage: Azure Blob, Google Cloud Storage and S3-compatible endpoints
File sources: .xlsx workbooks, CSV/TSV, JSON, NDJSON, Parquet and .duckdb databases
AES-256-GCM vault with a master key held by Windows Credential Manager, macOS Keychain or libsecret
Enterprise secret managers supported as vault backends: AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault
Connection definitions export and import as JSON with secrets stripped, for fleet-wide standard configuration

How it works

Settings → Connections defines a source: name, kind, host, database and a reference to its secret.
The secret itself is written to the vault, encrypted per record with a fresh random nonce and an authentication tag that makes tampering detectable rather than merely unlikely.
Connection files hold only what is safe to share — the vault reference, never the value.
Test Connection verifies reachability and credentials before the definition is saved.
An export bundle can be produced as metadata-only (safe to e-mail or commit) or with secrets encrypted under a passphrase.

Practices that keep it reliable

Distribute a metadata-only connection bundle to the team and let each machine supply its own credentials once
Use VERIFY-FULL for PostgreSQL wherever the certificate estate supports it — it is the only mode that authenticates the server you are actually talking to
Prefer a wallet or managed identity over a stored password where the platform offers one
For a server or a scheduled refresh use an identity that stores no secret — managed identity, workload identity, an IAM role — or a key pair; browser SSO needs someone at a desktop and cannot run unattended
Avoid passwords and personal access tokens for anything shared or scheduled, and use a pasted access token only to test — it usually expires within an hour

In a regulated environment

Encryption is only as good as where the key lives: keeping the vault master key in the OS keychain means a copied vault file is inert on any other machine.
Transport security is explicit rather than assumed — PostgreSQL modes run from DISABLE through VERIFY-FULL, SQL Server encrypts and validates certificates by default, and object storage is reached over HTTPS with SigV4 request signing.
Older RSA-wrapped vaults migrate automatically on first start, all-or-nothing, with every record read back and compared before anything is replaced.

Screens

Connections — sources defined once; secrets saved to the vault, never to the project.
Settings — appearance, grid defaults, connections, Git, semantic objects and advanced engine options.

Related guides

SQL reporting

Glossary terms on this page

KPI dashboard: definition

ATX Institute on LinkedIn

This site needs JavaScript for the full experience. Every page above is reachable without it.