Connect a Database

SignalPilot supports 11 SQL dialects. Connections are encrypted at rest with AES-GCM.

Supported databases

For full per-database connection fields, capabilities, and dialect gotchas, see each database's dedicated page (linked below).

Database	db_type	Cloud/Local	Tier
PostgreSQL	postgresql	Cloud + Local	1
MySQL	mysql	Cloud + Local	1
Snowflake	snowflake	Cloud	1
BigQuery	bigquery	Cloud	1
Amazon Redshift	redshift	Cloud	2
ClickHouse	clickhouse	Cloud + Local	2
Databricks	databricks	Cloud	2
SQL Server	mssql	Cloud + Local	2
Trino	trino	Cloud + Local	2
DuckDB	duckdb	Local	3
SQLite	sqlite	Local	3

Add a connection via the web UI

Go to http://localhost:3200 → Connections → Add Connection. Fill in the connection details for your database type.

Add a connection via API

add a connection via api

$ curl -X POST http://localhost:3300/api/connections \
  -H "Content-Type: application/json" \
  -d '{
$     "name": "my-warehouse",
$     "db_type": "duckdb",
$     "database": "/path/to/warehouse.duckdb"
$   }'

Connection examples by dialect

These are minimal examples. See each database's dedicated page (linked in the table above) for the full field reference, auth methods, and dialect-specific details.

PostgreSQL

postgresql

{
  "name": "prod-postgres",
  "db_type": "postgresql",
  "host": "db.example.com",
  "port": 5432,
  "database": "analytics",
  "username": "readonly",
  "password": "..."
}

Recommended: Create a read-only PostgreSQL user — the gateway enforces read-only at the SQL level, but defense-in-depth is good practice.

MySQL

mysql

{
  "name": "prod-mysql",
  "db_type": "mysql",
  "host": "db.example.com",
  "port": 3306,
  "database": "analytics",
  "username": "readonly",
  "password": "..."
}

SQLite

sqlite

{
  "name": "local-sqlite",
  "db_type": "sqlite",
  "database": "/data/analytics.db"
}

SQLite connections are local-only (the gateway must have filesystem access to the .db file).

SQL Server

sql server

{
  "name": "prod-mssql",
  "db_type": "mssql",
  "host": "sqlserver.example.com",
  "port": 1433,
  "database": "Analytics",
  "username": "readonly",
  "password": "..."
}

Snowflake

snowflake

{
  "name": "prod-snowflake",
  "db_type": "snowflake",
  "account": "xy12345.us-east-1",
  "database": "ANALYTICS",
  "warehouse": "COMPUTE_WH",
  "role": "ANALYST",
  "username": "...",
  "password": "..."
}

Databricks

databricks

{
  "name": "prod-databricks",
  "db_type": "databricks",
  "host": "adb-1234567890.azuredatabricks.net",
  "http_path": "/sql/1.0/warehouses/abcdef123456",
  "access_token": "..."
}

BigQuery

bigquery

{
  "name": "prod-bigquery",
  "db_type": "bigquery",
  "project": "my-gcp-project",
  "dataset": "analytics",
  "credentials_json": "{...service account JSON...}"
}

Amazon Redshift

redshift

{
  "name": "prod-redshift",
  "db_type": "redshift",
  "host": "my-cluster.abc123.us-east-1.redshift.amazonaws.com",
  "port": 5439,
  "database": "dev",
  "username": "readonly",
  "password": "..."
}

Redshift uses the PostgreSQL wire protocol. Both provisioned clusters and Redshift Serverless are supported. IAM auth (temporary credentials via GetClusterCredentials / Serverless GetCredentials) is available — see the Redshift page.

ClickHouse

clickhouse

{
  "name": "prod-clickhouse",
  "db_type": "clickhouse",
  "host": "my-host.clickhouse.cloud",
  "port": 9440,
  "database": "default",
  "username": "default",
  "password": "...",
  "protocol": "native"
}

The connector tries native TCP first (default port 9000, TLS 9440) and falls back to HTTP (port 8123, TLS 8443). Set protocol to native or http to force one. ClickHouse Cloud, on-premise, and self-hosted instances are supported.

Trino

trino

{
  "name": "prod-trino",
  "db_type": "trino",
  "host": "trino.example.com",
  "port": 8080,
  "username": "analyst",
  "password": "...",
  "catalog": "hive",
  "schema_name": "analytics"
}

Trino runs federated queries across catalogs. A password switches the connection to HTTPS. JWT, certificate, and Kerberos auth are also supported — see the Trino page.

Environment variables for connections

For self-hosted deployments, you can pre-configure connections via environment variables instead of the API. See Configuration for the variable names.

SSH tunneling

For databases that are not directly reachable from the gateway container, SSH tunneling is supported:

ssh tunnel config

{
  "name": "tunneled-postgres",
  "db_type": "postgresql",
  "host": "db.internal.example.com",
  "port": 5432,
  "database": "analytics",
  "username": "readonly",
  "password": "...",
  "ssh_tunnel": {
    "host": "bastion.example.com",
    "port": 22,
    "username": "ec2-user",
    "private_key": "-----BEGIN OPENSSH PRIVATE KEY-----..."
  }
}

SSRF allow-list (cloud mode)

In cloud mode, cloud warehouse connection parameters are validated against an allow-list of known hostnames to prevent SSRF attacks. The default allow-list covers:

• *.snowflakecomputing.com
• *.databricks.com / *.azuredatabricks.net
• bigquery.googleapis.com

Self-hosted deployments can extend this list via SP_SSRF_ALLOW_LIST.

Connection health

connection health

Tool: connection_health
→ prod-snowflake: p50=42ms, p95=180ms, p99=450ms, error_rate=0.1%
→ dev-duckdb: p50=2ms, p95=8ms, p99=15ms, error_rate=0.0%

Use connection_health to verify all connections are reachable and responding within acceptable latency.