What Are AI Data Connectors?

A data connector is software that lets an analytics product communicate with a database, application, API, file store, or other data system. It handles source-specific details so the product can access approved data without rebuilding the integration for every analysis.

A connector is not automatically a complete data pipeline. Depending on its architecture, it may copy records into a warehouse, query data where it already lives, or expose selected application objects and operations.

Why Data Connectors Exist

Early analytics stacks commonly moved data from operational systems into a central warehouse. Extract, transform, load (ETL) pipelines converted source data before loading it. As cloud warehouses made storage and transformation more flexible, extract, load, transform (ELT) became common: load data first, then model it in the destination.

Connectors grew out of that pipeline work. They packaged the recurring logic for database drivers, SaaS APIs, file formats, incremental syncs, and failures. Modern analytics products still use those patterns, but some now query sources directly or connect at the application layer instead of replicating everything.

How Data Connectors Work

Most production connectors address the same set of concerns, although their implementation varies by source and product.

1. Credentials and authentication

The connector authenticates with a database credential, API key, OAuth grant, service account, or another supported method. Good implementations protect secrets, request the smallest practical scope, support revocation, and make the owner and target account clear.

Authentication answers “may this connection access the source?” It does not prove that every table, endpoint, or operation is appropriate for analysis.

2. Schema discovery

The connector inspects what the source exposes: tables and columns, API resources and fields, file structure, or MCP tools and resources. It may also collect types, relationships, descriptions, and sample metadata.

Discovery is not a one-time guarantee. Sources change. A connector needs a way to detect new, renamed, or removed fields and to surface incompatible changes.

3. Extraction or querying

A replication connector reads records in batches or from a change stream. A federated connector translates and sends a query at request time. An application-level connector calls an API endpoint or approved tool.

Each method inherits source constraints such as pagination, transaction boundaries, query limits, rate limits, and permissions.

4. Normalization

Source values rarely arrive in one universal analytical shape. A connector may map data types, flatten nested responses, preserve source identifiers, standardize timestamps, or expose raw values for later modeling.

Normalization makes sources easier to use, but it can also hide meaning. Teams should be able to tell what was changed, what remained source-native, and how nulls, deletions, and type conflicts are handled.

5. Freshness

Freshness describes how current the available data is. It may depend on a sync schedule, change-data-capture lag, cache policy, source availability, or query time.

“Connected” does not mean “real time.” A useful connector reports the last successful access or refresh and makes expected delay visible.

6. Retries and recovery

Networks fail, credentials expire, schemas drift, and APIs throttle requests. Connectors often retry temporary failures with delays and resume from checkpoints.

Retries need limits and care. Repeating a non-idempotent operation can create duplicates or side effects, while skipping a failed page can create silent gaps.

7. Governance

Governance covers who may create and use a connection, which data is in scope, where copied data is stored, how long it persists, and which actions can modify a source. Source permissions, workspace roles, audit logs, retention rules, and credential rotation may all contribute.

The connector is an access path—not a substitute for a governance policy.

8. Observability

Operators need to see connection health, sync or query status, latency, volume, errors, retries, schema changes, and freshness. Alerts should distinguish a total failure from a partial or stale result.

Without observability, a connector can appear healthy while returning incomplete data.

Three Common Connector Architectures

Replication pipelines

Replication connectors copy selected data into a warehouse, lake, or product-managed store. They may use scheduled batch extraction, incremental cursors, or change data capture.

Best suited for: preserving history, joining many sources, isolating analytical workloads, and running repeated queries efficiently.

Limitations: data is delayed by the replication interval; copies increase storage, security, residency, and deletion obligations; schema changes and backfills require operational work.

Federation or query-time access

Federated connectors leave data in the source and query it when an analysis runs. The analytics product may translate its query into the source’s language and combine the result with other data.

Best suited for: reducing copies, accessing current source data, and exploring a system before building a pipeline.

Limitations: performance and availability depend on the source; analytical queries can compete with production workloads; cross-source joins and caching can complicate freshness and governance.

Application-level connectors

Application-level connectors communicate through a product’s API or MCP server. They expose domain objects or operations such as accounts, tickets, events, reports, or approved tools rather than direct table access.

Best suited for: preserving application semantics, respecting product-level permissions, and using capabilities the source intentionally exposes.

Limitations: the API may omit fields or history, enforce rate limits, change versions, or expose operations with side effects. API access is not necessarily read-only.

A product can use more than one architecture. For example, it might discover metadata through an API, query a database directly, and materialize selected results for reuse.

Benefits of Data Connectors

• Faster access to supported sources

• Reusable authentication and schema discovery

• Consistent handling for pagination, limits, and common errors

• Less source-specific code in each dashboard or agent workflow

• Central places to manage access and connection health

• A path to combine operational, behavioral, billing, or support context

Limitations and Risks

• A connector can expose only what the source and granted permissions allow.

• Freshness ranges from live queries to delayed batch copies.

• Replication can create duplicate stores and compliance obligations.

• Direct queries can add load to operational systems.

• Normalization can lose source-specific meaning.

• Retries, backfills, and schema drift can produce gaps or duplicates.

• Vendor-maintained connectors may lag behind source API changes.

• A successful connection does not establish that its data is accurate, well modeled, or safe for every user.

How to Evaluate a Data Connector

Ask these questions before relying on one:

• How does it authenticate, and can access be revoked or rotated?

• What data, schemas, endpoints, tools, and actions are in scope?

• Does it replicate data, query at runtime, or call application operations?

• Where are data and credentials processed, cached, and stored?

• What is the expected freshness, and where is the last success shown?

• How are pagination, deletions, schema changes, rate limits, and retries handled?

• Can a retry create a duplicate or repeat a side effect?

• What logs, alerts, and audit records are available?

• How does the connector affect source performance, cost, and compliance?

Data Connectors in Dreambase

Dreambase uses two related terms with different roles.

A Supabase Connection is required for Dreambase’s core analytics workflow. It links a workspace to the Supabase project that provides the primary database context. Review Supabase authentication for authorization details. If a workspace needs more than one project, see multiple Supabase projects.

Optional Connectors are separate. Adopting an optional connector in Dreambase means creating a Custom API or Custom MCP connection when an analytical question needs another system. See the Integrations overview, Custom API documentation, and Custom MCP documentation.

Not every integration is an analytical source. Slack, for example, may be an interface that receives a question or delivers a result. It becomes a data source only when Slack data is intentionally connected, scoped, and governed for analysis. Treating an interface, destination, and source as separate roles makes data movement and permissions easier to reason about.

Frequently Asked Questions

What is a data connector in simple terms?

A data connector is software that handles the source-specific work required for an analytics product to access approved data or operations.

What is the difference between a connector and a connection?

A connector is the reusable integration capability. A connection is one configured, authenticated instance linked to a specific database, project, API, or MCP server.

Does a data connector copy all source data?

Not necessarily. Replication connectors copy selected data, federated connectors query it where it lives, and application-level connectors retrieve selected objects or call approved operations.

Does Dreambase require connectors?

Dreambase requires a Supabase Connection for its core analytics workflow. Optional Connectors are separate and can be created as Custom API or Custom MCP connections when another system is needed.