Connections
Connecting a warehouse — read-only, per organisation, with the credentials you control.
Data Warehouse → Connections is where warehouses are registered.
Supported
| ClickHouse | HTTP interface |
| PostgreSQL | |
| MySQL / MariaDB |
Adding one
| Field | Notes |
|---|---|
| Name | Appears in every alert from it — make it recognisable |
| Type | |
| Host and port | |
| Database | |
| User and password | Read-only |
| TLS | Use it |
Create a dedicated read-only user with access only to the schemas AccelerUp needs. Statement validation refuses writes, but defence in depth costs nothing here and a credential is the thing that turns a mistake into an incident.
Testing
Test connects, runs a trivial query, and reports what came back — including the version and the latency. Do it before saving.
A connection that fails later produces a fault on every rule that uses it, named by connection, so you find out from the rule rather than from silence.
Query safety
| First token | Must be SELECT, WITH, EXPLAIN, DESCRIBE, DESC or SHOW |
| Write verbs | INSERT, UPDATE, DELETE, UPSERT, MERGE, REPLACE refused in statement position |
| Timeout | 2 minutes |
| Rows | Capped |
The guard checks statement positions, not whether a word appears anywhere
in the text. FROM system.part_log and a column called merge_count are both
fine.
Latency matters
A warehouse 90 ms away with a query that scans a lot is a query that takes seconds. Rules have a two-minute timeout, so a slow connection does not hold up other rules — but a rule that regularly takes 90 seconds is one you want to know about.
The cost monitor shows query duration by rule.
Related
- Explorer and SQL Lab
- SQL alerts
- Query audit — who ran what
Where this behaviour lives: frontend/src/app/dwh/connections/, backend/internal/integration/dwh_runner.go. If the code and this page disagree, the code is right — please fix the page.
Part of Data warehouse — Querying the warehouse, and alerting on what the query returns.