Database connectors — a growing catalog of SQL, NoSQL and data-warehouse engines

Every engine in the catalog

Find the database your team runs, click Install in the admin connector marketplace, and it is ready to govern. The catalog groups into three families, which is also how AccessFlow itself classifies them internally.

SQL

Relational engines run over pooled JDBC inside the AccessFlow process, with schema introspection and WHERE-clause row-level security. The first five have their own SQL dialect built in; ClickHouse rides the generic dialect, as an uploaded driver does.

PostgreSQL Built in

MySQL 1-click install

MariaDB 1-click install

Oracle 1-click install

SQL Server 1-click install

ClickHouse 1-click install

+ Custom driver Upload any driver

Cloud data warehouses

Warehouses connect through native engines that use each vendor's own authentication model — key-pair JWT or password, service-account JSON, and personal access tokens respectively — rather than a pooled JDBC connection.

Snowflake 1-click install

BigQuery 1-click install

Databricks 1-click install

NoSQL

Document, key-value, wide-column, search and graph engines each ship as a native engine plugin that speaks the database's own query language — no SQL translation layer in between.

MongoDB 1-click install

Couchbase 1-click install

Redis 1-click install

DynamoDB 1-click install

Cassandra 1-click install

ScyllaDB 1-click install

Elasticsearch 1-click install

OpenSearch 1-click install

Neo4j 1-click install

Engine reference — category, runtime and install path

Every engine carries a category that decides how AccessFlow loads it. Relational engines run in-process over a pooled JDBC connection; everything else runs as a self-contained engine plugin resolved on demand. Every engine links through to the connector setup guide.

Two pairs share one artefact: ScyllaDB is served by the Cassandra plugin and OpenSearch by the Elasticsearch plugin, because each pair is wire-compatible. ClickHouse is the one SQL engine outside the built-in five dialects — it carries the CUSTOM dialect and is resolved through its own classloader, which is exactly the mechanism an uploaded driver uses. Query languages, connection fields and the per-engine row-security rules are in the engine matrix →

How an install works

The catalog is declarative. Each connector is a small manifest describing display name, logo, default port and SSL mode, the connection template, and where to fetch the artefact — a Maven coordinate for JDBC drivers, a direct URL for engine plugins — together with that artefact's pinned SHA-256. Adding or updating a supported database is a data change, not a code change. Every artefact is verified against its pin at install time, and CI rebuilds each engine plugin and fails the build if the resulting checksum has drifted from the manifest.

Clicking Install downloads the artefact, verifies it against the pinned checksum, and caches it. That cache is shared by JDBC drivers and engine plugins alike and can be backed by a persistent volume in the Helm chart, so installs survive restarts instead of re-downloading. Nothing about a connector is "installed" in a database table — status is derived from what is in the cache, which means a restored volume is a restored install.

Non-relational artefacts are engine plugins rather than drivers: self-contained JARs implementing AccessFlow's engine SPI, discovered through Java's ServiceLoader and loaded into an isolated classloader with no transitive resolution, so two engines can never fight over a shared dependency version. This is why the container image does not have to ship every database driver on earth, and why adding an engine costs you a download instead of a redeploy. Air-gapped installs pre-seed the cache directory with the JARs they need and run with downloads disabled.

Outbound API connectors are registered rather than downloaded — there is no artefact to pin — but once registered they are governed identically, and the review, masking and audit guarantees are the same across every connector type. See the security architecture →

Anything not in the catalog — upload your own driver

If your engine speaks JDBC but is not in the list, an admin uploads its driver JAR, enters the driver class and its SHA-256, and creates a Custom datasource against it. The JAR is org-scoped and gets the same isolated classloader a catalog connector does; queries against it are parsed, reviewed and audited exactly like any other. For engines with no JDBC driver at all, the engine-plugin SDK documents the service-provider interface a native engine implements — the same contract every plugin in the catalog is built on. That route is a contribution rather than an upload: a new engine ships as a plugin project plus a manifest merged into the catalog.

Common questions