ArchitectureA supervised JVM-class runtime — OLTP on seven engines, OLAP on three. AI-native, MCP-native, observable as plain SQL.Read the architecture
Está viendo la edición Perú. Está viendo la edición Colombia. You're viewing the Pakistan edition. Cambiar a la edición global →Cambiar a la edición global →Switch to the global edition →
Product Release

Vector store expansion — Qdrant official gRPC client and Redis Stack as a third backend

The vector store layer expands to three backends : Qdrant migrates from a hand-authored HTTP client to the official gRPC API, retiring 654 lines of custom serialisation ; Redis Stack joins as the third option, co-locating HNSW vector search with operational cache data on a single Redis cluster.

The platform's vector store abstraction — the interface the RAG pipeline, the knowledge-base assistant and the agent document-retrieval tools call — now covers three backends : pgvector on PostgreSQL, Qdrant and Redis Stack. All three implement the same VectorDatabase interface ; the RAG pipeline does not know which backend handles the retrieval call. This release ships two changes that complete the current backend set : Qdrant migrates to the official gRPC client, and Redis Stack is added as the third option.

Qdrant — official gRPC client

  • Custom HTTP client retired. The Qdrant integration shipped with a hand-authored HTTP client — custom request serialisation, custom response parsing, custom filter encoding. At 654 lines, maintaining it across Qdrant API versions was a recurring cost. The official Qdrant gRPC client replaces it entirely : the type-safe protobuf contract handles serialisation, the official client manages connection lifecycle, and Qdrant API updates reach the platform as a library bump rather than a code change.
  • Interface parity maintained. The VectorDatabase interface the RAG pipeline calls is unchanged ; the gRPC migration is contained within the Qdrant adapter. Existing deployments using Qdrant see no change at the application layer.
  • Minimum-score filtering. The Qdrant adapter gains minimum cosine-similarity thresholding in the same release : retrievals below the configured floor are dropped before they reach the context window, reducing noise from distant matches that would otherwise degrade LLM reasoning quality.

Redis Stack — vector search co-located with operational data

  • RediSearch HNSW index. Redis Stack's RediSearch module adds HNSW vector indexing on top of standard Redis key-value storage. The adapter translates the VectorDatabase interface to the RediSearch query protocol ; deployments interact with Redis Stack through the same API surface as Qdrant and pgvector.
  • Co-location advantage. Deployments that already run a Redis cluster for session state, caching and pub/sub can add a vector index to the same cluster without provisioning a separate Qdrant instance or a PostgreSQL extension. The embedding pipeline writes vectors to the Redis index alongside the cache write in the same operational envelope.
  • Configurable key prefix. All RediSearch document keys for a given knowledge base share a configurable prefix ; multiple knowledge bases coexist on the same Redis cluster without key-space collision.

Choosing a backend

  • pgvector for workloads where the document metadata lives in PostgreSQL and transactional consistency between the document record and its embedding matters.
  • Qdrant for large independent corpora where the vector workload justifies a dedicated store, or when advanced filter-criteria support and horizontal scaling are the binding requirements.
  • Redis Stack for deployments where operational latency is paramount and a Redis cluster is already the operational data plane — adding a fourth system just for vectors is unnecessary.

Application code — the RAG pipeline, the agent retrieval tools, the knowledge-base assistant — is unaffected by which backend is active. Backend selection is a configuration choice ; migration between backends is a reindex operation, not a code change.

See the feature →

← All posts