Qdrant stores your index in its own format. ManyVector stores it in your bucket.
Qdrant is an excellent vector database — fast, well-maintained, and simple to operate. The key difference is where your data lives. Qdrant writes to its own proprietary segment format on disk. ManyVector writes to standard objects in your S3/GCS/R2/Azure bucket — readable by any tool, movable at any time.
Standard format
no proprietary on-disk segment format
CoW branching
instant namespace forks, zero duplication
S3 · GCS · R2
any S3-compatible backend you already use
ManyVector vs Qdrant, side by side.
Feature
ManyVector
Qdrant
Storage format
✓ Standard objects in your S3 / GCS / R2 bucket
✗ Proprietary segment format on disk
Data portability
✓ Standard files — any tool can read, copy, or archive them
✗ Requires Qdrant tooling to access segments
Storage cost model
✓ S3 / GCS / R2 commodity rates — no markup
✗ Server disk / RAM rates
RAM requirements
✓ Minimal — index served from object storage
✗ Hot collections cached in RAM
Data sovereignty
✓ Your bucket, your cloud account
✗ Self-host or Qdrant Cloud (their infrastructure)
Namespace branching
✓ Copy-on-write instant branching built in
✗ Not supported
Full-text search (BM25)
✓ Native BM25 — no preprocessing required
✓ Native (added recently)
Hybrid search (RRF)
✓ BM25 + vector with RRF fusion, built-in
✓ Supported
Self-hosting simplicity
✓ Single binary + bucket — no disk management
✓ Single binary + local disk
Why teams switch from Qdrant.
Data portability
Segment files you can't read without Qdrant.
Qdrant's segment files are Qdrant's segment files — you can't open them with standard tooling. With ManyVector, our index is sitting in S3 as ordinary objects. We can inspect, copy, or archive it without running any vector database at all.
Cost model
S3 rates, not server disk rates.
Qdrant's self-hosted approach requires disk proportional to your index — and if you use Qdrant Cloud, you're paying their margin on top of compute. ManyVector's cost is just S3: roughly $0.023 per GB per month, regardless of index size.
Namespace branching
A/B tests without duplicating collections.
We run A/B tests on embeddings constantly. With Qdrant we had to duplicate collections — expensive and slow. ManyVector's copy-on-write branching forks a namespace in milliseconds and shares storage until we write to the branch.
Common questions
Is there a performance difference between ManyVector and Qdrant?
Qdrant's mmap-based disk access with in-RAM caching is highly optimized for single-server latency. ManyVector fetches index segments from object storage, which introduces network round-trips for cold reads. For hot workloads where frequently accessed segments remain in local cache, performance is comparable. For latency-critical applications serving data that must be in RAM at all times, benchmark both before committing.
What does 'standard object storage format' mean in practice?
ManyVector writes index segments as ordinary objects to your bucket using documented, open formats. You can list them with the AWS CLI, copy them to another region with standard S3 tooling, or archive them to Glacier — without running ManyVector. Qdrant's segment files require Qdrant's own tooling to interpret.
Can I migrate my existing Qdrant collections to ManyVector?
Yes. Use Qdrant's scroll API to export all points (vectors + payloads) in batches, then upsert them into ManyVector via the REST API. Vectors are float arrays — there is no format conversion. A migration script for common collection sizes typically runs in under an hour.
How does copy-on-write namespace branching work?
When you fork a namespace, ManyVector creates a new namespace record that references the same underlying object storage segments as the source. No data is copied. As you write to the branch, only the new or modified segments are written — the unchanged segments are shared. This makes it practical to maintain many simultaneous namespace variants (staging, per-tenant, experiment branches) without multiplying your storage costs.