PostgreSQL pgvector co-locates the embedding index with the relational workload — the right answer when the data and the vectors belong in the same transactional boundary. Qdrant is the right answer for the complementary case : large document corpora, multi-tenant knowledge bases and retrieval workloads that deserve their own storage budget, independent IOPS allocation and a scaling axis separate from the OLTP engine. This release adds Qdrant as the platform's first dedicated vector database, reachable from server-side scripts through the Ax.vectordb namespace.
Client architecture
- Direct gRPC client. The platform connects to the Qdrant cluster over the native gRPC API. The client is initialised from the host and port declared in the platform's credential store ; scripts receive a typed
VectorDatabasehandle without managing connection state or serialisation. - Collection configuration builder. Collections — Qdrant's equivalent of a table in the vector index — are created through a typed builder : dimension count, distance metric (cosine, Euclidean, dot product), HNSW parameters and payload-index declarations are expressed in typed Java before the gRPC call is issued.
- Embedding store operations. The embedding store interface covers insert, upsert, delete-by-identifier and the core retrieval operation — top-k nearest-neighbour query with optional filter criteria applied against the payload fields stored alongside each vector.
Payload metadata and filtered retrieval
- Payload-side filtering. Qdrant stores arbitrary JSON payload alongside each vector ; filter criteria narrow the nearest-neighbour search to the subset of points that match payload conditions before the distance computation. Tenant-scoped retrieval — "retrieve from this department's documents only" — becomes a native Qdrant filter rather than a post-retrieval application join.
- Platform permission model on the caller side. Qdrant access is governed by the platform's role model ; a script that does not hold the vector-database permission cannot invoke these methods regardless of which Qdrant collection the underlying credentials can reach.
Qdrant and pgvector are complementary choices on the platform : pgvector for vector workloads that belong in the same operational envelope as the transactional data, Qdrant for workloads that need a dedicated store with payload filtering and independent scaling. The embedding pipeline, the RAG query transformer and the knowledge-base assistant resolve against whichever backend is configured for the department — application code is backend-agnostic.