Skip to content
Monomer

Add a warehouse connection

A connector tells Monomer which warehouse to use and which warehouse identity to use there. Give it a recognizable name, such as Analytics production.

Ask your warehouse administrator for an endpoint reachable from Monomer, the database or catalog to use, and a dedicated read-only warehouse account allowed to read the needed tables and metadata. A read-only account is required. Your laptop’s localhost does not identify a warehouse reachable from Monomer’s server. Use the TLS settings required by your administrator.

Monomer does not guarantee read-only access. If the connection account has write permissions, Explorers and their Agents can modify warehouse data. Native SQL checks help prevent common mistakes; they do not replace warehouse permissions.

Do not grant this account permission to execute procedures, use pass-through queries, or invoke remote/external functions. Review these permissions for each warehouse: PostgreSQL and Redshift procedures, functions, and external connections; BigQuery procedures, remote functions, and connection access such as EXTERNAL_QUERY; Trino procedures and pass-through table functions such as system.query; Snowflake procedures, external functions, and integrations; and Databricks procedures, external functions, and connections. Have the warehouse administrator review direct and inherited privileges using the vendor’s access controls. Monomer does not inspect the side effects of these functions. Catalog selection limits browsing and modeling, not the data reachable by SQL.

You need permission to manage connectors in the workspace. Enter credentials directly in the connector form. Do not put them in an agent prompt, document, connector name, or support message.

  1. Select your workspace and open Sources → Connectors.
  2. Select Create connector, choose the source type, and select Next.
  3. Enter a display name and fill the source settings and credential method below, then select Create. Use values from your administrator; examples such as port numbers are not credentials.
  4. Catalog opens with the Choose tables to load panel for the new connector. For a source with a catalog level, choose catalogs first and select Continue.
  5. Wait for the list of schemas. This first listing is the connection check: on success the panel says Connected and how many schemas it found.
  6. Choose tables and select Save and refresh, as described in Select and refresh Catalog. Then run a small SQL query to confirm access to the intended data.

There is no separate connection test. If the first listing fails, the panel names the cause, such as a rejected sign-in or an unreachable host, and nothing is saved to Catalog. Owners can select Replace credentials or Edit settings there and return to the same panel after saving; others are asked to contact a workspace Owner. Select Try again after the fix.

SourceRequired settingsCredential choicesOptional settings
PostgreSQLHost, Port, DatabaseUsername and passwordSchema, SSL mode
BigQueryProject ID, LocationService account JSON—
SnowflakeAccount, Warehouse, DatabaseUsername and password; username and private keySchema, Role; private key passphrase
DatabricksHost, Warehouse IDAccess token; OAuth client ID and secretCatalog, Schema
TrinoHost, Port, CatalogUsername and passwordSchema, SSL, SSL verification
RedshiftHost, Port, DatabaseUsername and password; IAMSchema, SSL mode

For Redshift IAM, provide AWS access key ID, AWS secret access key, AWS region, cluster ID, and database user. For Databricks, provide the SQL warehouse ID and workspace host. Monomer accepts 1–128 alphanumeric characters for the ID; this is Monomer’s input restriction, not a vendor format guarantee. Cluster HTTP paths are not supported. For BigQuery, provide the complete service account JSON and the location in which your data is queried. These values must belong to the same source environment.

Open the connector details and use its settings or credential replacement action. Settings and credentials are changed separately. A replacement credential must contain all fields for the chosen method; existing secret values are never displayed. PostgreSQL and Redshift database names are fixed when created, so create a separate connector if you need another database.

An agent reads the connector, follows its advertised edit or credential replacement entry, and calls monomer_describe with that entry before constructing the call. Read result.path after the change to confirm its non-secret settings.

After a change, repeat the refresh or query that failed. If access still fails, share the connector name, source type, visible error, and request reference with your administrator, without sharing secret values.

Workspace Owners can delete a connector from its details. Type the connector’s name to confirm. The dialog lists the semantic models that read its tables; they won’t run until they use another connector.

Deleting removes the connector’s tables from Catalog and destroys its saved credentials. Explore runs and refresh history stay and show it as “Deleted connector”. A deleted connector no longer counts toward the workspace’s connector limit, and its name can be reused. Deletion can’t be undone.

If a Catalog refresh is running for the connector, cancel it in Catalog, then delete. Agents with the Owner role follow the connector read’s advertised delete entry and call monomer_invoke with that exact path and action, omitting input.