Connectors

KyroDB runs above existing stores through certified connectors. The current first-party paths are pgvector first and Qdrant secondary. Other vector stores, including Pinecone, require a certified connector profile before production use.

A connector is production-safe only when scope and filters are executable and testable, and when the configured freshness ownership mode has testable evidence: event-feed ACKs, scoped mutation ACKs, native watermarks, or immutable snapshot versions as applicable.

Vector databases such as pgvector and Qdrant are retrieval backends. KyroDB is the correctness runtime above that retrieval path: it decides whether context is fresh, scoped, traceable, and safe for an agent to use.

Connector contract

Production connectors must:

• enforce tenant and namespace in the backend query path;
• validate filter keys and parameterize filter values;
• declare freshness ownership mode honestly;
• fail loudly for unsupported operations;
• avoid cross-tenant watermarks and connector-wide scans unless explicitly safe;
• keep secrets out of serialized config and logs.

Do not serve production traffic through a connector that only documents scope behavior. Scope must be enforced by the store query or mutation path.

pgvector

Use pgvector when PostgreSQL owns the vector table and scope columns. This is the first KyroDB developer path because most teams already keep product knowledge, support content, or app data in Postgres-compatible systems.

In the managed console, pgvector is the only interactive provisioning flow today. KyroDB accepts a Postgres DSN, stores it in a server-side secret store, queues a managed runtime, and waits for deployment and health promotion.

Local fixture:

docker compose -f examples/pgvector-live/docker-compose.yml up -d

The pgvector connector enforces:

• tenant and namespace filtering;
• validated filter keys;
• parameterized filter values;
• safe connection string serialization;
• scoped write-through mutation ACKs when configured.

Write-through upsert/delete require ownership_mode=write_through, a namespace column, mutation_key_mode=tenant_namespace_id, and a primary or unique key on (tenant_column, namespace_column, id_column) in that order. Do not treat a database write as freshness proof unless KyroDB can verify the mutation ACK boundary.

Qdrant

Use Qdrant when payload fields can enforce tenant, namespace, document id, and metadata boundaries.

Local fixture:

docker compose -f examples/qdrant-live/docker-compose.yml up -d

Qdrant is secondary today. It supports scoped search, fetch, and delete, but not write-through upsert, write-through ownership, or native watermarks. Use event-feed change events or invalidations for freshness unless your deployment has a certified connector profile.

Custom stores

Custom stores are allowed only when they preserve the KyroDB contract.

Minimum requirements:

• executable scope filters;
• bounded request and response sizes;
• deterministic document ids;
• clear watermark semantics;
• clear mutation ACK semantics;
• safe error redaction;
• conformance tests for scope isolation and freshness behavior.

In production mode, KyroDB rejects opaque custom stores that cannot be certified. That is intentional. A context runtime is only useful if it can say no.