Connect to Your Entire Data Stack
DataFuseAI connects to a wide range of databases, warehouses, storage systems, and various file formats, — so data can move where it needs to without brittle workarounds. Integrations are designed to be reusable, secure, and predictable as environments evolve. 50+ native integrations, with support for custom databases when your stack doesn’t fit neatly into a preset category.
RDBMS (25)
MSSQL
Oracle
PostgreSQL
MySQL
Snowflake
Redshift
SAP HANA
Vertica
Teradata
MonetDB
CockroachDB
MariaDB
IBM DB2
RDS MariaDB
RDS MSSQL
RDS MySQL
RDS MySQL Aurora
RDS Oracle
RDS PostgreSQL Aurora
RDS PostgreSQL
RDS IBM DB2
Azure MySQL
Azure PostgreSQL
Azure SQL Server
Azure Cosmos PostgreSQL
NoSQL (6)
BigQuery
Cassandra
Couchbase
MongoDB
Azure Cosmos NoSQL
Azure Cosmos MongoDB
AWS (8)
RDS MariaDB
RDS MSSQL
RDS MySQL
RDS MySQL Aurora
RDS Oracle
RDS PostgreSQL Aurora
RDS PostgreSQL
RDS IBM DB2
Azure (6)
Azure MySQL
Azure PostgreSQL
Azure SQL Server
Azure Cosmos PostgreSQL
Azure Cosmos NoSQL
Azure Cosmos MongoDB
GCP (1)
BigQuery
File (1)
Upload
FTP (1)
FTP
SFTP (1)
SFTP
S3 (1)
S3
FAQ
Frequently Asked Questions About Data Connectors
The catalogue is organised by category rather than by vendor list: relational databases (RDBMS), NoSQL stores, cloud data warehouses, cloud-hosted database services on AWS, Azure, and GCP, object storage such as S3, file sources, FTP and SFTP locations, and REST APIs. Each connector is pre-built, so a source is configured on a form rather than by writing integration code for it.
A saved, reusable definition of how to reach one source: the host or base URL, the authentication it requires, and the settings that describe the connection. Registering it once means every pipeline and query references the profile instead of repeating credentials, and rotating a password or key becomes one edit rather than a search through every job that touched that system.
Through the generic REST API connector, by describing the API rather than coding against it. A connection profile holds the base URL and the authentication type, and each endpoint is registered with its path, method, query parameters, and pagination strategy. Two decisions do most of the work for any API: how it authenticates, and how it pages through results — settle those and the rest is field selection.
Run the built-in Connection Check on the profile. It confirms the source is reachable and the credentials carry the permissions the pipeline will need, so a wrong password or a blocked port surfaces during setup rather than at the first scheduled run. Doing this before a pipeline is built is the difference between a configuration error and a failed overnight job.
No. Sources are configured through connection profiles on a form — connection details, authentication, and the fields you want — and used from the pipeline canvas without integration code. That is the point of the connector catalogue: the work becomes describing the source rather than maintaining a script for each one.
Yes. Object storage such as S3, cloud-hosted services on AWS, Azure, and GCP, plain file sources, and FTP or SFTP locations are all first-class source types alongside relational and NoSQL databases. A pipeline can therefore combine a database table with a delivered file in the same run, without staging the file into a database first.
No. A connection profile only describes how to reach a system; nothing is read until a pipeline or query asks for it. What moves, when it moves, and where it lands are decided by the pipeline you build — the source system stays in place and remains the system of record.
Credentials live on the connection profile rather than inside individual pipelines, and secrets are masked once saved so they are not readable back from the interface. Because access to profiles follows the same role-based group permissions as the rest of the workspace, who can use or edit a given source is an access-control decision rather than a matter of who happens to know the password.