Skip to content

Databases

detectkit is database-agnostic: metrics, detectors and alerting work the same way regardless of where your data lives. Three backends are supported as first-class, fully working targets:

ClickHousePostgreSQLMySQL
StatusSupportedSupportedSupported
Install extradetectkit[clickhouse]detectkit[postgres]detectkit[mysql]
Driverclickhouse-driverpsycopg2-binarypymysql
Default port9000 (native)54323306
Min version20.3+12+8.0+
Location modeltwo databasesone database, two schemastwo databases
profiles.yml location fieldsinternal_database, data_databasedatabase + internal_schema, data_schemainternal_database, data_database
Internal dedupReplacingMergeTree (version-collapse)enforced PK + ON CONFLICT upsertenforced PK + ON DUPLICATE KEY UPDATE

Install everything at once with detectkit[all-db].

detectkit keeps two kinds of tables apart:

  • Internal tables (_dtk_*) — datapoints, detections, task locks, alert state. detectkit owns and auto-creates these in the internal location.
  • Your data — the source tables your metric SQL reads from, in the data location.

The “location” is a database on ClickHouse and MySQL, and a schema on PostgreSQL (a PostgreSQL connection targets one database, and the internal/data tables live in schemas inside it).

The same logical guarantee — at most one row per primary key, newest wins — is delivered by ReplacingMergeTree on ClickHouse and by an enforced primary key plus a version-aware upsert on PostgreSQL/MySQL. You don’t configure any of this; detectkit picks the right strategy per backend.

  • ClickHouse — the original target; ideal for large analytical event tables.
  • PostgreSQL — schema-based; the database must already exist, detectkit creates the schemas.
  • MySQL — database-based; requires MySQL 8.0+.

Only the connection and the SQL dialect of your metric queries differ between backends — detectors, alerting, the CLI and the project layout are identical. See Profiles for the full field reference and Installation for the driver extras.