Data warehouse connectors let you pull structured records from Snowflake or Databricks directly into Spectron's authoritative knowledge store. Each record in the query result becomes a typed knowledge node, giving your agents instant access to product catalogues, customer records, pricing tables, or any other structured data your warehouse holds.
How it works
When a warehouse connector syncs, Spectron:
Connects to the warehouse using the credentials in
configExecutes the configured SQL query (or scans the referenced table)
Maps each record to a
knowledgenode – column names become field keys, column values are stored with their native typesComputes a deterministic node ID from the primary-key columns to enable idempotent re-syncs
Updates or creates nodes as needed; records present in the previous sync but absent from the current one are soft-deleted
Because warehouse data is already structured, no chunking or embedding pipeline is applied. Retrieval against warehouse-sourced nodes uses direct field-level lookup and BM25 keyword search; vector search is available if you configure embedding for specific text columns.
Snowflake
Configuration
| Field | Type | Description |
|---|---|---|
account | string | Snowflake account identifier (e.g. xy12345.eu-west-1) |
warehouse | string | Virtual warehouse to use for query execution |
database | string | Target database |
schema | string | Target schema |
username | string | Snowflake username |
password | string | Snowflake password (store in your secrets manager; Spectron does not log credential values) |
query | string | SQL query whose result set is synced |
primary_keys | array of strings | Column names that uniquely identify a record; used to compute node IDs |
Create a Snowflake connector
Databricks
Configuration
| Field | Type | Description |
|---|---|---|
host | string | Databricks workspace hostname (e.g. adb-1234567890.12.azuredatabricks.net) |
http_path | string | HTTP path to the SQL warehouse (e.g. /sql/1.0/warehouses/abc123) |
token | string | Databricks personal access token or service principal token |
query | string | SQL query whose result set is synced |
primary_keys | array of strings | Column names that uniquely identify a record |
catalog | string | (optional) Unity Catalog name |
schema | string | (optional) Schema name |
Create a Databricks connector
Record-to-node mapping
Given a query result like:
| product_id | name | price | category |
|---|---|---|---|
P001 | Wireless Headphones | 149.99 | Electronics |
P002 | Standing Desk | 599.00 | Furniture |
Spectron creates two knowledge nodes:
The node ID is stable across syncs: if record P001 changes in the warehouse, the existing node is updated rather than replaced, preserving any cross-references from experiential memory.
Incremental sync patterns
For large tables, retrieve only records that have changed since the last sync by parameterising the query with the connector's last_sync_at timestamp. Spectron exposes this value in the connector status response:
Use it to build an incremental query:
A cleaner pattern is to store the watermark in your warehouse query itself using a Snowflake dynamic table or a Databricks Delta table with TIMESTAMP_DIFF filtering. This keeps the connector configuration static while the query automatically narrows its window.
Scheduling recommendations
| Data type | Recommended schedule |
|---|---|
| Reference data (products, categories) | Every 6–24 hours |
| Transactional records (orders, events) | Every 30–60 minutes |
| Real-time operational data | Use the REST API for push-based ingestion instead |
Warehouse connectors are pull-based and incur compute cost on the warehouse side. Avoid polling intervals shorter than 15 minutes unless the data volume is small and the warehouse is lightly loaded.