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.

Production traffic requires executable scope enforcement in the store query or mutation path; documented conventions alone are not enough.

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 connection string, stores it server-side, starts managed runtime setup, and promotes the endpoint after health checks pass. Managed pgvector runtimes are event-feed first by default: your app writes Postgres directly, commits, then sends KyroDB scoped change events with stable source_event_id values.

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 only when explicitly certified and provisioned.

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. They are not enabled by default for managed pgvector runtimes. A database write becomes freshness proof only when 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.