Skip to main content
A database connector is a set of query templates. Each template becomes one tool: an agent supplies the named parameters, the query runs read-only where the connection string lives, and the rows come back capped and masked. On the hosted service that place is your organization’s data-plane agent; Danube stores a reference to the connection string and never the string.

Engines

You write every template the same way, with :name placeholders; the engine rewrites them per driver. Whatever the engine, the template is validated before it runs: one SELECT (or WITH ... SELECT), no comments, no second statement, no data-modifying keyword anywhere.

The connection reference

connection_ref names where the connection string is, in one of three forms: A value in that field (anything with a scheme, a host or a password) is refused at registration, by the dashboard and by the agent. What the variable holds, per engine:

A read-only role

The validator refuses writes, and Postgres, Redshift, MySQL and ClickHouse refuse them a second time on the connection. For the others the role is the second layer, so create one that can only read:
BigQuery: grant the service account roles/bigquery.dataViewer on the dataset and roles/bigquery.jobUser on the project.

Drivers in the agent image

The published image ships no database driver. Build your own from dataplane-agent/ with the engines you need, comma-separated:
install_drivers.sh installs the pinned lines from requirements-drivers.txt for those engines and nothing else; an engine that is not built in fails a query with driver_missing. postgres and redshift share one driver.

Register

From Connector Builder, choose Database, the organization as owner (Runs inside your network is preselected), the engine, the reference and the queries. Preview import lists the tools it would create. Over the API:
Each query becomes a method: SQL tool at /queries/<slug> with the engine, the reference and the template in its metadata. A parameter used in the template and not declared is reported as a warning: an agent will not know to send it, and a call without it fails with bad_request: missing parameter.

Limits

  • One read statement per template. Comments, ;, dollar quotes and # are refused.
  • At most 1,000 rows per call (max_rows on the connector lowers it); truncated: true in the result says more matched.
  • A 30 second statement timeout by default (timeout_seconds, up to 55 inside the 60 second dispatch budget) and a 10 second connect timeout.
  • Cells are returned JSON-safe: dates as ISO 8601, decimals as numbers, bytes as base64. Credential-shaped values in rows are masked like any other tool result.
  • POST /v1/connectors/database/test, /introspect, /infer and /dry-run connect from the control plane and are for self-hosted deployments; for a local_only connector they answer 400 and the test is a tool run after registration.

Troubleshooting