# Which Vector Databases Does DBX Support? Qdrant, Milvus, and Weaviate Integration Explained

> Discover DBX support for Qdrant, Milvus, and Weaviate via its unified Rust driver. Integrate vector databases seamlessly with the VectorClient interface.

- Repository: [skyler/dbx](https://github.com/t8y2/dbx)
- Tags: deep-dive
- Published: 2026-07-04

---

**DBX provides native support for Qdrant, Milvus, and Weaviate through a unified Rust driver that abstracts HTTP handling, authentication, and query normalization behind the `VectorClient` interface.**

DBX is an open-source database exploration platform that treats vector databases as first-class data sources. Understanding which vector databases DBX supports and how they are integrated reveals a layered architecture where driver-specific REST APIs are normalized into a generic tabular model. The implementation lives primarily in the `dbx-core` crate, where a thin HTTP wrapper handles protocol differences between Qdrant's gRPC-over-HTTP, Milvus's RESTful API, and Weaviate's schema-based endpoints.

## Supported Vector Database Engines

According to the source code in [`crates/dbx-core/src/db/vector_driver.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/db/vector_driver.rs), DBX supports four vector search engines through the `VectorDbKind` enum (lines 40-46). While the primary focus is on **Qdrant**, **Milvus**, and **Weaviate**, the driver also includes support for **ChromaDB**. Each backend receives identical treatment through the unified `VectorClient` abstraction, though they maintain distinct REST endpoint shapes and authentication schemes.

## Core Driver Architecture

The vector database integration centers on a thin HTTP client wrapper that normalizes driver-specific behaviors into a consistent interface.

### The VectorDbKind Enum

The `VectorDbKind` enum defines the supported backends and provides human-readable labels for each driver. Located at lines 40-46 in [`vector_driver.rs`](https://github.com/t8y2/dbx/blob/main/vector_driver.rs), this enum acts as the type discriminator that determines which endpoint patterns and authentication headers to apply throughout the request lifecycle.

### The VectorClient HTTP Wrapper

The `VectorClient` struct (lines 59-89) serves as the primary interface for all vector database operations. It wraps a `reqwest::Client` and stores three critical pieces of state: the `VectorDbKind` driver type, the base URL, and optional authentication credentials. The client exposes helper methods (`get`, `post`, `put`, `delete`) that automatically inject the correct authentication headers based on the selected driver.

## Authentication Handling

DBX handles authentication diversity through the `vector_auth` function (lines 118-133). This utility selects the appropriate auth scheme—**basic**, **bearer token**, **API-key**, or **Chroma token**—based on the `VectorDbKind` and supplied credentials. For example, Milvus requires a bearer token constructed as `"user:pwd"`, while Qdrant uses the password field as an API-key header, and Weaviate accepts a JWT token as a Bearer token.

## Driver-Specific REST Patterns

Each vector database exposes collections and metadata through distinct REST shapes. The driver implements separate branches for connection testing and collection listing that map to each backend's specific endpoints.

### Qdrant Integration

For **Qdrant**, the driver uses `GET /collections` for health checks and `GET /collections/{name}` for retrieving collection details. These endpoints map to the Qdrant REST API's standard collection management interface, allowing DBX to list available collections and inspect their vector configurations.

### Milvus Integration

**Milvus** requires POST-based discovery endpoints. The driver calls `POST /v2/vectordb/collections/list` to enumerate collections and `POST /v2/vectordb/collections/describe` to fetch detailed schema information. This reflects Milvus's v2 REST API design, which uses JSON payloads even for listing operations.

### Weaviate Integration

**Weaviate** uses `GET /v1/meta` for health verification and `GET /v1/schema` for collection introspection. The driver treats Weaviate's schema objects as equivalent to collections, normalizing the semantic graph structure into DBX's tabular view.

## Unified Query Interface

The `find_documents` function (lines 424-476) provides a driver-agnostic facade for vector search. It constructs database-specific query payloads—Qdrant's `points/scroll`, Milvus's `entities/query`, or Weaviate's `/objects` GET—and forwards them to `execute_rest_query`. Results are normalized into a `QueryResult` struct that matches DBX's generic tabular model, allowing the UI and agent tools to process vector search results identically regardless of the backend.

## Database Type Mapping

Higher-level connection logic bridges the user-facing `DatabaseType` enum with the internal `VectorDbKind`. In [`crates/dbx-core/src/models/connection.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/models/connection.rs) (lines 1076-1080), the code maps `DatabaseType::Qdrant`, `DatabaseType::Milvus`, and `DatabaseType::Weaviate` to their corresponding `VectorDbKind` variants. This wiring ensures that DBX's UI, CLI, and agent tools all use the same code path in [`vector_driver.rs`](https://github.com/t8y2/dbx/blob/main/vector_driver.rs) regardless of which vector store the user selects.

## Practical Implementation Examples

The following Rust snippets demonstrate how to instantiate clients for each supported vector database and execute basic operations.

Creating clients for each database type:

```rust
use dbx_core::db::vector_driver::{
    VectorClient, VectorDbKind,
    test_connection, list_collections,
};
use std::time::Duration;

// Qdrant client with API-key authentication
let qdrant = VectorClient::new(
    VectorDbKind::Qdrant,
    "http://localhost:6333",
    Some("admin"),
    Some("secret"),  // Used as API-key
    false,
    Duration::from_secs(5),
);

// Milvus client with bearer token authentication
let milvus = VectorClient::new(
    VectorDbKind::Milvus,
    "http://localhost:19530",
    Some("root"),
    Some("pwd123"),  // Formatted as "user:pwd" bearer token
    false,
    Duration::from_secs(5),
);

// Weaviate client with JWT token
let weaviate = VectorClient::new(
    VectorDbKind::Weaviate,
    "http://localhost:8080",
    None,
    Some("my-jwt-token"),
    false,
    Duration::from_secs(5),
);

```

Testing connections and listing collections:

```rust
// Verify connectivity and list collections
test_connection(&qdrant, Duration::from_secs(3)).await?;
let collections = list_collections(&qdrant).await?;
println!("Found collections: {:?}", collections);

```

Executing vector searches:

```rust
use dbx_core::db::vector_driver::find_documents;

// Search first 10 documents in "articles" collection
let result = find_documents(&qdrant, "articles", 0, 10).await?;
println!("Retrieved {} documents", result.total);

```

## Summary

- **DBX supports Qdrant, Milvus, Weaviate, and ChromaDB** through a unified driver architecture located in [`crates/dbx-core/src/db/vector_driver.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/db/vector_driver.rs).
- **The `VectorClient` struct** abstracts HTTP transport and authentication, exposing consistent `get`, `post`, `put`, and `delete` methods across all backends.
- **Authentication normalization** occurs in `vector_auth` (lines 118-133), handling API-keys, bearer tokens, and basic auth transparently.
- **Driver-specific REST endpoints** are isolated in connection testing and collection listing functions, while **vector search is unified** through `find_documents` (lines 424-476) which normalizes results into `QueryResult`.
- **Type mapping** in [`crates/dbx-core/src/models/connection.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/models/connection.rs) (lines 1076-1080) bridges the UI-facing `DatabaseType` enum with the internal `VectorDbKind` driver selector.

## Frequently Asked Questions

### Does DBX support vector databases other than Qdrant, Milvus, and Weaviate?

Yes. According to the `VectorDbKind` enum definition in [`crates/dbx-core/src/db/vector_driver.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/db/vector_driver.rs) (lines 40-46), DBX also includes a driver for **ChromaDB** alongside the three primary vector databases. All four backends receive equal treatment through the unified `VectorClient` interface.

### How does DBX handle different authentication schemes between vector databases?

DBX centralizes authentication logic in the `vector_auth` function (lines 118-133 of [`vector_driver.rs`](https://github.com/t8y2/dbx/blob/main/vector_driver.rs)). This function inspects the `VectorDbKind` and provided credentials to inject the correct headers: API-key for Qdrant, Base64-encoded `"user:password"` bearer tokens for Milvus, and JWT Bearer tokens for Weaviate.

### Where does the mapping between UI connection types and driver implementations occur?

The mapping lives in [`crates/dbx-core/src/models/connection.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/models/connection.rs) at lines 1076-1080. Here, the generic `DatabaseType` enum variants (selected in the UI or CLI) are translated into concrete `VectorDbKind` values used by the vector driver, ensuring consistent behavior across DBX's desktop app, CLI, and agent tooling.

### Are vector search results normalized into a standard format?

Yes. The `find_documents` function (lines 424-476) normalizes driver-specific response payloads into a generic `QueryResult` struct. This allows DBX to present Qdrant's `points`, Milvus's `entities`, and Weaviate's `objects` through the same tabular interface without requiring UI-level branching logic.