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

Every engine in the catalog

Find the database your team runs and it is ready to govern — PostgreSQL is already there, and everything else takes one click on Install in the admin connector marketplace. The catalog groups into three families, which is also how AccessFlow itself classifies them internally.

SQL

Relational engines are reached through the database's own driver, with schema introspection and WHERE-clause row-level security. AccessFlow loads that driver once and keeps the connections to the database open. 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 AccessFlow engines that use each vendor's own authentication model: key-pair JWT or password for Snowflake, service-account JSON for BigQuery, and a personal access token for Databricks SQL.

Snowflake 1-click install

BigQuery 1-click install

Databricks 1-click install

NoSQL

Document, key-value, wide-column, search and graph databases are each governed by an AccessFlow engine 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, connection and install path

Every engine carries a category that decides how AccessFlow reaches it. For a relational database AccessFlow loads that database's own driver; for everything else it loads an AccessFlow engine built for that database, downloaded and checksum-verified the first time you install it. Every engine links through to the connector setup guide.

Two pairs share one download: ScyllaDB is served by the Cassandra engine and OpenSearch by the Elasticsearch engine, 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 loaded on its own, exactly the way a driver you upload yourself is, so its driver version cannot disturb any other datasource. 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 file it needs — a public package repository for a database driver, a direct download URL for an AccessFlow engine — together with that file's pinned SHA-256. Adding or updating a supported database is a data change, not a code change. Every download is verified against its pin at install time, and CI rebuilds each AccessFlow engine and fails the build if the resulting checksum has drifted from the manifest.

Clicking Install downloads the file, verifies it against the pinned checksum, and caches it. Database drivers and AccessFlow engines share that one cache, which 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.

Every database that is not relational is governed by an AccessFlow engine rather than by a database driver: one self-contained download, built by AccessFlow against a documented contract, carrying its own copy of everything it needs and kept separate from every other engine — so two engines can never fight over the same dependency version. This is why the container image does not have to ship every database driver on earth, and why adding a database costs you a download instead of a redeploy. Air-gapped installs put the files they need into the cache directory up front and run with downloads switched off.

Outbound API connectors are registered rather than downloaded — there is no file 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 upload belongs to your organization alone and is kept as separate from everything else as a catalog connector is; queries against it are parsed, reviewed and audited exactly like any other. For databases with no JDBC driver at all, the engine SDK guide documents the contract an AccessFlow engine implements — the same one every engine in the catalog is built on. That route is a contribution rather than an upload: a new engine ships as its own project plus a manifest merged into the catalog.

Common questions