mindSDB connectors: which data sources are supported and how do I configure credentials securely?

Most teams hit the same wall the moment they try to make AI actually useful: your data is scattered across databases, warehouses, CRMs, and file systems—and every new integration turns into a mini data engineering project. With MindsDB, the whole point is to bring AI to where your data already lives, not force you into yet another ETL layer or copy of your data.

This guide walks through two things you care about most:

Which data sources MindsDB connectors support today
How to configure credentials in a way that keeps everything inside your trust boundary and preserves governance

Why connectors matter in an AI data platform

If you want reliable AI-powered analytics and document intelligence, three things have to be true:

You can reach the right systems in real time
That means connecting directly to operational databases, warehouses, and SaaS APIs—without standing up pipelines or replicas.
You don’t have to normalize everything yourself
A good connector layer abstracts differences between MySQL, Snowflake, Salesforce, and your file store so AI can query in place with consistent semantics.
Security and governance are inherited, not re-implemented
The AI layer should respect the same RBAC, permissions, and scopes you already enforce, instead of inventing its own shadow model.

MindsDB’s connector architecture is built around those constraints: over 300 connectors, query-in-place execution, and user-scoped credentials—no centralized credential hoarding, no unlogged data hops.

MindsDB connector coverage: what you can plug in

MindsDB is designed as a federated AI query engine for your data stack. It supports hundreds of sources, but they fall into a few major families.

1. Relational databases (OLTP systems)

These are usually the systems of record running your core applications.

Typical examples MindsDB supports:

PostgreSQL
MySQL / MariaDB
Microsoft SQL Server
Oracle Database

With these connectors, you can:

Run conversational analytics directly against production schemas
Perform joins across databases (e.g., PostgreSQL + MySQL) without building custom bridges
Let MindsDB’s cognitive engine plan and generate SQL while you keep full visibility into the queries it runs

Because execution is query-in-place, you’re not creating new data copies or maintaining sync jobs—the AI engine sits logically next to your databases and asks questions on demand.

2. Cloud data warehouses and lakehouses

For analytics teams, the warehouse is the canonical source of truth. MindsDB connects to:

Snowflake
BigQuery
Amazon Redshift
Databricks

These connectors let you:

Ask cross-system questions that combine warehouse facts with operational data from other systems
Replace slow dashboard cycles with plain-English questions that compile down to optimized SQL
Keep your existing modeling and governance in place while removing the last-mile “ask and answer” bottleneck

Again, no ETL into MindsDB; it uses your warehouse as the execution engine.

3. NoSQL and document databases

When your product or logs live in non-relational stores, you still want them available to AI:

MongoDB
Cassandra
CouchDB
Other key-value, document, or wide-column stores supported via the 300+ connector catalog

MindsDB abstracts away the query semantics so you can:

Ask high-level questions about usage, events, or entities in these systems
Join NoSQL data with warehouse or relational tables for a complete picture

4. Time-series and event data

For operational analytics, monitoring, and metrics intelligence, MindsDB integrates with time-series databases (and event backends via specific connectors). This enables:

Root cause analysis across logs, metrics, and business data
Natural language queries like “What changed in signups 30 minutes before the error rate spiked?”

5. SaaS applications and business systems

Operational truth isn’t only in databases. This is where broad connector coverage really matters.

MindsDB supports over 300 data connectors, including major enterprise SaaS platforms such as:

CRM systems like Salesforce
Marketing platforms like HubSpot
Productivity suites (Google Workspace, Microsoft 365, etc.)
Other line-of-business apps (support, billing, ERP, HR, and more) through the same connector catalog

This lets MindsDB:

Run conversational analytics across systems—e.g., “Show me MQLs from HubSpot that converted in Salesforce but haven’t been invoiced yet.”
Power AI search and document intelligence directly on top of content in productivity suites and collaboration tools
Respect native permissions (who can see which account, document, or ticket) so you’re not duplicating access rules.

6. Files, documents, and knowledge bases

AI is only as useful as the documents it can safely read and reason over. MindsDB connects to:

File systems and object storage
Cloud drives and document management systems
Content formats including PDFs, Word, HTML, text, and more

Here, the connector is paired with MindsDB’s Knowledge Base capabilities:

Content is chunked, embedded, and kept current via AutoSync
Semantics are enriched with metadata
Document-level citations and reasoning are surfaced in answers
The system enforces native permissions inherited from the source—if you couldn’t open the file in the original system, you won’t get answers from it in MindsDB

How MindsDB connectors actually work (without ETL)

The design principle is simple: bring the cognitive engine to the data, not the other way around.

When you add a connector:

MindsDB discovers the schema (for databases and structured APIs) or content inventory (for document systems).
The cognitive engine learns how to talk about your entities—“projects,” “tickets,” “cases,” “orders”—in natural language.
When a user asks a question, MindsDB runs a multi-step pipeline:
- Plans the query in natural language
- Generates SQL or API calls
- Validates the plan and queries
- Executes against the connected source(s)
- Returns an answer with citations and reviewable SQL (where applicable)

All of this is logged. Every planning step, generated query, validation pass, and execution trace is auditable. That’s essential if you care about production analytics and not just demos.

There’s no data movement or replication into MindsDB. It does not host, store, or transfer your customer data out of your environment. You deploy it where your data already lives—on-prem or in your own cloud (VPC)—and it reaches out to your systems from inside that trust boundary.

Secure credential configuration: principles first

The most important part of connecting data sources is not the driver—it’s the credential model. MindsDB is built with a few non-negotiable rules:

Each user configures their own credentials to access only the data sources they’re entitled to use.
User accounts are completely independent: credentials, permissions, and query scopes are isolated per user.
MindsDB enforces that users cannot view or query data outside their authorized scope, preserving enterprise-grade governance.
MindsDB does not host or train on your data. It runs inside your infrastructure; your credentials never leave your boundary.

Think of MindsDB as a query orchestrator with a cognitive layer on top. It knows how to ask your systems questions, but access is always mediated by your own security controls.

Step-by-step: configuring a connector with secure credentials

The exact UI/API steps differ by deployment, but the security pattern is consistent across sources.

1. Decide the scope of access

Before touching MindsDB, define what this integration should see:

Which database(s), schema(s), and table(s)?
Which Salesforce objects and fields?
Which folders or sites in your document system?

Then create a least-privilege identity in the source system:

A dedicated DB user (e.g., mindsdb_analytics) with read-only access to specific schemas
A Salesforce connected app with a profile that restricts objects and fields
A cloud drive service account limited to chosen folders

This keeps data governance anchored in the system of record, not in the AI layer.

2. Create or select the user in MindsDB

In your MindsDB deployment:

Create a user account (or assign an existing one) that should own this connection.
Make sure their role in MindsDB aligns with your governance model (e.g., who can create connectors, who can only query them).

Because accounts are isolated, one user’s credentials never grant access to another user.

3. Add the connector with user-scoped credentials

From there, you configure the connector—either via UI or code. Conceptually, you’ll provide:

Connection details (host, port, URL, instance ID)
Authentication (username/password, OAuth token, client cert, or API key)
Optional constraints (default database, allowed schemas, or query scopes)

For example, a database configuration might capture:

Host: analytics-db.internal
Port: 5432
Database: warehouse
User: mindsdb_analytics
SSL mode / certificate details

Those credentials are stored inside your deployment boundary and are only used when that user (or an authorized application acting as them) issues a query that touches the connector.

4. Verify and test within the trust boundary

Once configured:

Run a test query from MindsDB to the source (e.g., SELECT 1 or a simple table sample).
Confirm the user can only see what they should—no extra schemas or documents.
Check that all access is being logged and audited in both MindsDB and the underlying system.

Because MindsDB logs planning, generation, validation, and execution, you can:

Inspect the SQL or API calls it generates
Confirm that it is not querying unauthorized objects
Prove compliance for internal and external audits

5. Roll out to additional users safely

When you move beyond a single user:

Either have other users configure their own credentials for the same connector type (honoring their access)
Or, if you use a shared service account for read-only analytics, treat that as a governed shared identity, and restrict who can attach to it inside MindsDB

In both cases, you maintain:

DB / SaaS-side governance (roles, permissions, row/column-level rules)
MindsDB-side governance (RBAC, which users can create or reuse connectors, what projects they can query in)

Governance controls you should expect around connectors

If you’re running MindsDB in production, connectors aren’t just a convenience—they’re part of your governance surface. The platform is built with several layers to make this defensible:

RBAC and SSO/LDAP
Control who can:
- Create connectors
- Modify or delete them
- Use them in projects or applications
  And map those permissions to your identity provider.
Native permission inheritance
For document and SaaS connectors, MindsDB respects the underlying system’s ACLs—it doesn’t invent a new permission model on top.
Auditing and observability
Every query step is logged:
- Which user or service queried which connector
- What plan and SQL/API calls were generated
- Latency, retrieval behavior, and success/failure This instrumentation is part of MindsDB’s broader “continuous evaluation” posture (tracking embedding freshness, retrieval accuracy, latency).
Data residency and trust boundary
MindsDB is deployed in your own VPC or on-prem data center. There is no centralized SaaS service siphoning your credentials or data. Connectors simply route traffic inside your owned environment.

Putting it all together: a connector playbook

If you’re planning how to wire MindsDB into your stack, here’s a practical pattern:

Start with your primary database + warehouse
- PostgreSQL / MySQL / SQL Server / Oracle
- Snowflake / BigQuery / Redshift / Databricks
  This gives you a fast win: conversational analytics and cross-system SQL without touching ETL.
Add your CRM and marketing systems
- Salesforce, HubSpot, and other GTM SaaS tools via the 300+ connector catalog
  Now you can answer questions that span revenue, product, and finance without manual exports.
Layer in document repositories
- Connect file systems, cloud drives, and DMS
- Turn on the Knowledge Base with AutoSync and native permissions
  This unlocks AI search, summarization, and extraction across contracts, tickets, SOPs—always citation-backed.
Codify governance
- Enforce least-privilege identities per connector
- Use RBAC and SSO/LDAP mapping in MindsDB
- Monitor logs and tie queries back to users and applications
Iterate with confidence
- Add new connectors as new systems come online
- Rely on the same query-in-place and credential model for each addition
- Keep all AI-powered insights inside your existing security perimeter

Final takeaway

MindsDB connectors are built to make AI-powered analytics and document intelligence feel like a natural extension of your existing data estate:

Broad coverage: over 300 connectors across relational databases, warehouses, NoSQL stores, SaaS apps like Salesforce and HubSpot, productivity suites, and file systems.
Query-in-place: no ETL, no replicas, no data movement—MindsDB sends queries to where data already lives.
Strong governance: user-scoped credentials, isolation between accounts, native permission inheritance, and full auditability of every query.

If you want to see how this looks against your own stack—PostgreSQL here, Snowflake there, Salesforce over the top—the fastest path is a live walkthrough.

Get Started