Connectors overview
The built-in connectors that move data in and out of a CocoIndex flow — object stores, message streams, and relational, vector, and graph databases. Many work as a source, a target, or both.
A connector links a CocoIndex flow to an external system. It plays one or both of two roles:
- As source — imports rows into a flow, with change capture so only what actually changed is reprocessed.
- As target — exports target states from a flow and keeps the external system in sync via incremental upserts and deletions.
Some connectors do both. Each page documents the APIs for whichever roles the system supports, under ## As source / ## As target sections.
Each connector lives in cocoindex::connectors::<name> behind a Cargo feature of the same name: cocoindex::connectors::postgres needs the postgres feature, cocoindex::connectors::qdrant the qdrant feature, and so on. Two names differ: the Google Drive source is cocoindex::connectors::gdrive behind the google_drive feature, and the local filesystem connector is cocoindex::resources::fs, which is always compiled (its live watch needs the fs_live feature).
The Discord source is Python-only: the Rust SDK has no Discord connector, so this page does not list it. See the Python Discord connector.
Sources
Connectors that feed rows into a flow.
| Connector | Also a target | Reads from |
|---|---|---|
| Local filesystem | ✅ | Local files and directories, with live watch mode |
| Amazon S3 | S3 buckets and S3-compatible stores (MinIO, Tigris) | |
| Azure Blob Storage | Azure Blob Storage containers | |
| Google Drive | Google Drive folders, via a service account or a personal account signed in with OAuth | |
| OCI Object Storage | Oracle Cloud object storage, driven by OCI Streaming events | |
| Postgres | ✅ | PostgreSQL tables via read_table |
| Kafka | ✅ | Topics as live keyed maps or raw event streams |
| Iggy | ✅ | Apache Iggy topics as live streams or maps |
Targets
Connectors that export data out of a flow. They’re grouped by the kind of store, but most also handle vector search.
Relational and analytical
| Connector | Also a source | Notes |
|---|---|---|
| Postgres | ✅ | Relational database with pgvector (ivfflat / hnsw) |
| Apache Doris | Analytical database, HNSW/IVF vector + inverted full-text indexes | |
| SQLite | Embedded database, optional vector search via sqlite-vec | |
| Snowflake | Cloud data warehouse — managed DDL, MERGE upserts, incremental deletes | |
| BigQuery | Cloud data warehouse with managed DDL, MERGE upserts, incremental deletes |
Vector databases
| Connector | Notes |
|---|---|
| LanceDB | Embedded vector DB, vector + full-text (FTS) indexes |
| Qdrant | Single, named, and multi-vector points with schemaless payloads |
| Turbopuffer | Namespaces with single or named vectors |
| Valkey | Search indexes with vector similarity (HNSW / FLAT) |
| zvec | Embedded, in-process vector DB with dense and sparse vectors |
Property graph
| Connector | Notes |
|---|---|
| Neo4j | Property graph over Bolt — node and relationship tables, vector indexes |
| FalkorDB | Redis-backed Cypher graph, per-graph multitenancy, vector indexes |
| SurrealDB | Multi-model — normal and relation (edge) tables, vector indexes |
Message streams
| Connector | Also a source | Notes |
|---|---|---|
| Kafka | ✅ | Produce messages as target states with at-least-once semantics |
| Iggy | ✅ | Produce messages to Apache Iggy topics |
Beyond the built-ins
If you need a system that isn’t listed here, implement a custom target connector as a building block of your flow.