Qdrant: native vector and hybrid search on Watasu

Qdrant is now available on Watasu. Add a dedicated search service to your app, connect with an official Qdrant SDK, and keep control of your collections, indexes, and queries. Watasu manages provisioning, TLS, placement, backups, and recovery.

Qdrant is written in Rust and runs without a JVM. It gives search its own compute, memory, and storage budget, so indexing and retrieval can scale independently of your primary database.

Search by meaning, words, and context

Semantic search helps when a user’s wording differs from the document they need. Sparse-vector retrieval adds precise term matching. Qdrant’s native hybrid Query API can combine their results, with payload filters to narrow the search by workspace, document type, date, or another attribute.

That supports document search, product discovery, recommendations, and retrieval for AI applications. Your application still owns authorization: build the correct filters, enforce access at your API boundary, and keep database credentials out of the browser.

Keep authoritative records in PostgreSQL or your existing primary store. Feed Qdrant through a durable indexing pipeline that handles updates, deletes, and retries. Watasu provides the database; embedding generation and synchronization remain part of your application.

Your SDK, directly

Create and attach the service with the CLI:

watasu addons:create qdrant:standard-0 --app my-app
watasu addons:wait ADDON_NAME

Watasu supplies QDRANT_URL, QDRANT_GRPC_URL, QDRANT_API_KEY, QDRANT_READ_ONLY_API_KEY, and QDRANT_CA_CERT to the attached app. Use the supplied CA for private TLS connections; the Qdrant guide includes a working Python SDK example.

REST and gRPC go straight to Qdrant. Collection settings, payload indexes, sharding, quantization, and consistency use the upstream APIs. Connections are private by default, with optional authenticated public TLS endpoints for clients outside Watasu.

Three tiers, eleven sizes

Pick the protection you need, then the capacity:

Premium distributes peers evenly across Nuremberg, Falkenstein, and Helsinki. Standard and Premium default to three shard copies and two acknowledgements per write. With managed placement enabled, Watasu distributes automatically sharded collections according to their configured replication factor, including across Premium locations.

Protection depends on the data layout. A collection configured with one replica still has one copy, even on Premium. Custom shard placement remains under your control. The dashboard reports observed replicas, quorum, and location coverage separately from the plan name, so you can see what is actually protected.

Size the workload, not the document count

Seven hundred million short vectors and seven hundred million large document embeddings are very different workloads. Dimensions, payloads, indexes, replication, ingestion rate, and query concurrency all affect capacity. Quantization and on-disk settings give you additional controls to evaluate against your recall and latency requirements.

Plan disk figures are per peer. Replicas consume physical space, and indexes, WAL, and optimization need headroom. Every peer also gets separate snapshot working space equal to its data disk.

Capacity increases copy shard replicas before retiring old peers. Adding peers does not automatically increase an existing collection’s shard count; choose that layout for your workload, or reindex into a new collection and switch a native alias. The pricing page lists every size.

Recovery beyond replication

All tiers support manual backups. Standard and Premium also schedule daily backups, with configurable retention from one to thirty-five days. Watasu captures native shard snapshots, verifies uploaded bytes, and marks the backup complete only when every shard is covered.

Restores build a new private, unattached add-on and reconstruct its replicas. You can inspect the restored data before deciding to switch applications. These backups record an online capture interval, not a database-wide point-in-time recovery position.

Health checks track the actual service, and interrupted lifecycle operations retain progress for retry. Replication helps with peer failures; backups provide a separate recovery path. Neither removes the need to test your application’s indexing and recovery behavior.

Get started

Create Qdrant from your app’s Add-ons page or the CLI. The documentation covers native clients, collection protection, backups, capacity changes, and public endpoints. The updated Watasu agent plugin includes the same workflows for supported coding agents.