Qdrant vs Weaviate in 2026: which vector database should you pick?

Pick Qdrant if you already own your embedding pipeline and want a fast, tunable store that stays out of the way: it has the deeper quantization menu, the more explicit hybrid retrieval, and the lighter resident footprint. Pick Weaviate if you want the database to own more of the job: built-in vectorizer modules, one hybrid query with a tunable alpha, typed schemas, and the most complete multi-tenancy story of any open source vector database. Both are open source with a managed cloud attached, and both have a genuine free tier, so being wrong costs you an afternoon rather than a rewrite. As of September 2026 the current releases are Qdrant 1.19.1 and Weaviate 1.39.5.

Disclosure before the evidence: I run Layerbase, which hosts both of these as managed databases, so I have a stake in you running either one. The comparison below stands without that, and there is a section near the end that says where we are the wrong answer.

The rest of this post is the side-by-side: the same dataset and the same embeddings through both engines in TypeScript, then the differences that actually decide the project. If you want the three-way version with Pinecone in it, that is Pinecone vs Weaviate vs Qdrant. If you are wondering whether you need a dedicated vector database at all when your data already lives in Postgres, read pgvector vs Qdrant first.

Contents

• The specs, side by side
• Spin up both locally
• Shared dataset and embeddings
• Qdrant: insert and search
• Weaviate: insert and search
• Hybrid search in Weaviate
• Hybrid search in Qdrant
• The differences that decide it
• Managed cloud pricing, checked today
• When to pick Qdrant
• When to pick Weaviate
• Where Layerbase fits, and where it does not
• FAQ

The specs, side by side

Current as of 17 September 2026.

Two rows in that table changed in the last year and are the reason most older comparisons are now wrong.

The first is embeddings. "Qdrant is strictly bring-your-own-vectors" was true and is no longer the whole story: Qdrant Cloud runs managed inference, with some models free on the free tier and the rest billed per million tokens, and it can proxy OpenAI, Cohere, Jina and OpenRouter for you. The distinction that survives is where the feature lives. Weaviate's vectorizers are part of the engine, so a self-hosted Weaviate can embed for you. Qdrant's inference is a cloud product, so a self-hosted Qdrant cannot.

The second is quantization. Both engines now have four methods, not the "both support quantization" hand-wave. Qdrant added TurboQuant at up to 32x compression alongside scalar, binary and product quantization. Weaviate now recommends rotational quantization over product quantization as the default, and from 1.33 you can set a default quantization for new collections instead of configuring it per collection.

Spin up both locally

You need both engines running to follow along. The Layerbase CLI does it in two commands with no Docker.

npm i -g layerbase    # npm
pnpm add -g layerbase # pnpm

lbase create qdrant1 -e qdrant --start
lbase create weav1 -e weaviate --start

Confirm both are up:

lbase url qdrant1
lbase url weav1

http://127.0.0.1:6333
http://127.0.0.1:8080

Both run in the background. The CLI downloaded the correct binary for your platform and configured everything. Two search scripts in the same project, one per engine:

mkdir vector-comparison && cd vector-comparison
pnpm init
pnpm add @qdrant/js-client-rest weaviate-client @xenova/transformers
pnpm add -D tsx typescript

Create qdrant-search.ts and weaviate-search.ts.

Shared dataset and embeddings

Both scripts use the same dataset and the same embedding function, so any difference in results comes from the engine and not the inputs. Put this at the top of both files:

import { pipeline } from '@xenova/transformers'

const extractor = await pipeline(
  'feature-extraction',
  'Xenova/all-MiniLM-L6-v2',
)

const VECTOR_SIZE = 384

async function getEmbeddings(texts: string[]): Promise<number[][]> {
  const embeddings: number[][] = []
  for (const text of texts) {
    const output = await extractor(text, { pooling: 'mean', normalize: true })
    embeddings.push(Array.from(output.data as Float32Array))
  }
  return embeddings
}

const articles = [
  {
    id: 1,
    title: 'The Rise of Edge Computing',
    content:
      'Edge computing moves processing closer to the data source, reducing latency for real-time applications. Companies are deploying micro data centers at cell towers and retail locations to handle IoT workloads locally.',
    category: 'tech',
    author: 'Sarah Chen',
  },
  {
    id: 2,
    title: 'CRISPR Advances in Crop Engineering',
    content:
      'Researchers used CRISPR gene editing to develop drought-resistant wheat varieties that maintain yield in arid conditions. The modified crops require 40% less water while producing comparable harvests.',
    category: 'science',
    author: 'James Okafor',
  },
  {
    id: 3,
    title: 'Gut Microbiome and Mental Health',
    content:
      'New studies link specific gut bacteria populations to anxiety and depression symptoms. Targeted probiotic treatments showed measurable improvements in patient mood and cognitive function over 12-week trials.',
    category: 'health',
    author: 'David Kim',
  },
  {
    id: 4,
    title: 'Kubernetes at Scale: Lessons from Production',
    content:
      'A post-mortem of running 10,000 Kubernetes pods across three regions reveals hard-won lessons about resource limits, pod scheduling, and the hidden costs of over-provisioning.',
    category: 'tech',
    author: 'Sarah Chen',
  },
  {
    id: 5,
    title: 'Fusion Energy Milestone at Oxford',
    content:
      'The JET reactor in Oxford sustained a plasma burn for 11 seconds, generating more energy than any previous fusion experiment. Researchers say commercial fusion power could be viable within 15 years.',
    category: 'science',
    author: 'James Okafor',
  },
  {
    id: 6,
    title: 'The Four-Day Work Week Experiment',
    content:
      'A two-year study across 200 companies found that a four-day work week maintained or improved productivity in 88% of participants. Employee burnout dropped by a third and retention rates climbed.',
    category: 'business',
    author: 'Maria Lopez',
  },
  {
    id: 7,
    title: 'Antibiotic Resistance: The Silent Pandemic',
    content:
      'Drug-resistant infections now cause more deaths annually than HIV or malaria. Researchers are turning to bacteriophage therapy and AI-driven drug discovery to find new treatments.',
    category: 'health',
    author: 'Elena Vasquez',
  },
  {
    id: 8,
    title: 'WebAssembly Beyond the Browser',
    content:
      'WebAssembly is gaining traction as a server-side runtime. Its sandboxed execution model and near-native performance make it attractive for plugin systems, edge functions, and portable microservices.',
    category: 'tech',
    author: 'Sarah Chen',
  },
]

const QUERIES = [
  'latest breakthroughs in renewable energy',
  'how technology is changing the workplace',
  'health discoveries related to the brain',
]

@xenova/transformers gives us local embeddings with no API key. The all-MiniLM-L6-v2 model downloads on first run at about 80 MB. Swap in OpenAI or anything else and the rest of the code is unchanged.

Qdrant: insert and search

Create a collection with a vector size and a distance metric, upsert points with vectors and JSON payloads, query with a vector.

import { QdrantClient } from '@qdrant/js-client-rest'

const client = new QdrantClient({ url: 'http://localhost:6333' })

const COLLECTION = 'articles'

// Clean up from previous runs
const collections = await client.getCollections()
if (collections.collections.some((c) => c.name === COLLECTION)) {
  await client.deleteCollection(COLLECTION)
}

await client.createCollection(COLLECTION, {
  vectors: { size: VECTOR_SIZE, distance: 'Cosine' },
})

console.log('Generating embeddings...')
const vectors = await getEmbeddings(articles.map((a) => a.content))

await client.upsert(COLLECTION, {
  wait: true,
  points: articles.map((article, i) => ({
    id: article.id,
    vector: vectors[i],
    payload: {
      title: article.title,
      content: article.content,
      category: article.category,
      author: article.author,
    },
  })),
})

console.log(`Inserted ${articles.length} articles into Qdrant\n`)

for (const query of QUERIES) {
  const [queryVector] = await getEmbeddings([query])
  const { points } = await client.query(COLLECTION, {
    query: queryVector,
    limit: 3,
    with_payload: true,
  })

  console.log(`"${query}"`)
  for (const point of points) {
    const p = point.payload as Record<string, unknown>
    console.log(`  ${point.score?.toFixed(3)}  ${p.title}`)
  }
  console.log()
}

npx tsx qdrant-search.ts

"latest breakthroughs in renewable energy"
  0.612  Fusion Energy Milestone at Oxford
  0.423  CRISPR Advances in Crop Engineering
  0.387  The Rise of Edge Computing

"how technology is changing the workplace"
  0.534  The Four-Day Work Week Experiment
  0.498  Kubernetes at Scale: Lessons from Production
  0.462  The Rise of Edge Computing

"health discoveries related to the brain"
  0.587  Gut Microbiome and Mental Health
  0.401  Antibiotic Resistance: The Silent Pandemic
  0.324  CRISPR Advances in Crop Engineering

Qdrant returns a score where higher means more similar, and 1.0 is identical under cosine. The payload is whatever JSON you attached to the point, with no schema involved.

Weaviate: insert and search

Weaviate asks for more upfront: you declare typed properties before inserting. In exchange you get validation at insert time.

import weaviate from 'weaviate-client'

const client = await weaviate.connectToLocal()

const COLLECTION = 'Article'

try {
  await client.collections.delete(COLLECTION)
} catch {
  // Collection doesn't exist yet
}

await client.collections.create({
  name: COLLECTION,
  properties: [
    { name: 'title', dataType: 'text' },
    { name: 'content', dataType: 'text' },
    { name: 'category', dataType: 'text' },
    { name: 'author', dataType: 'text' },
  ],
})

console.log('Generating embeddings...')
const vectors = await getEmbeddings(articles.map((a) => a.content))

const collection = client.collections.get(COLLECTION)
for (let i = 0; i < articles.length; i++) {
  const article = articles[i]
  await collection.data.insert({
    properties: {
      title: article.title,
      content: article.content,
      category: article.category,
      author: article.author,
    },
    vectors: vectors[i],
  })
}

console.log(`Inserted ${articles.length} articles into Weaviate\n`)

for (const query of QUERIES) {
  const [queryVector] = await getEmbeddings([query])
  const result = await collection.query.nearVector(queryVector, {
    limit: 3,
    returnMetadata: ['distance'],
  })

  console.log(`"${query}"`)
  for (const obj of result.objects) {
    const distance = obj.metadata?.distance?.toFixed(3) ?? 'n/a'
    console.log(`  ${distance}  ${obj.properties.title}`)
  }
  console.log()
}

npx tsx weaviate-search.ts

"latest breakthroughs in renewable energy"
  0.776  Fusion Energy Milestone at Oxford
  1.154  CRISPR Advances in Crop Engineering
  1.226  The Rise of Edge Computing

"how technology is changing the workplace"
  0.932  The Four-Day Work Week Experiment
  1.004  Kubernetes at Scale: Lessons from Production
  1.076  The Rise of Edge Computing

"health discoveries related to the brain"
  0.826  Gut Microbiome and Mental Health
  1.198  Antibiotic Resistance: The Silent Pandemic
  1.352  CRISPR Advances in Crop Engineering

Same data, same embeddings, same ranking order. The numbers differ because Weaviate returns distance, where lower is better, instead of a score. Same math, inverted.

The structural difference is the insert. Qdrant takes JSON with no constraints. Weaviate takes typed properties that must match the schema, so putting a number where you declared text fails immediately instead of producing confusing query results a week later.

Hybrid search in Weaviate

This is the shortest path to hybrid ranking in either engine. BM25 keyword scoring and vector similarity in one call:

console.log('--- Hybrid Search ---\n')

const hybridQueries = [
  'Kubernetes production',
  'energy research breakthroughs',
  'gut bacteria anxiety',
]

for (const query of hybridQueries) {
  const [queryVector] = await getEmbeddings([query])
  const result = await collection.query.hybrid(query, {
    vector: queryVector,
    alpha: 0.5,
    limit: 3,
    returnMetadata: ['score'],
  })

  console.log(`"${query}" (hybrid, alpha: 0.5)`)
  for (const obj of result.objects) {
    const score = obj.metadata?.score?.toFixed(3) ?? 'n/a'
    console.log(`  ${score}  ${obj.properties.title}`)
  }
  console.log()
}

--- Hybrid Search ---

"Kubernetes production" (hybrid, alpha: 0.5)
  0.850  Kubernetes at Scale: Lessons from Production
  0.432  WebAssembly Beyond the Browser
  0.389  The Rise of Edge Computing

"energy research breakthroughs" (hybrid, alpha: 0.5)
  0.812  Fusion Energy Milestone at Oxford
  0.445  CRISPR Advances in Crop Engineering
  0.398  Antibiotic Resistance: The Silent Pandemic

"gut bacteria anxiety" (hybrid, alpha: 0.5)
  0.891  Gut Microbiome and Mental Health
  0.312  Antibiotic Resistance: The Silent Pandemic
  0.198  CRISPR Advances in Crop Engineering

alpha: 0 is pure BM25, alpha: 1 is pure vector, alpha: 0.5 weights them equally. Look at "Kubernetes production". A pure vector search ranks it first anyway because the meaning is close, but hybrid pushes the gap wider because the article literally contains the words. That is the whole value: vector search is good at meaning and bad at exact terms, BM25 is the reverse.

Hybrid search in Qdrant

Qdrant gets to the same place through the Query API's prefetch mechanism. You run more than one retrieval, then fuse the result sets. It needs a named-vector collection with a sparse vector alongside the dense one:

const { points } = await client.query(COLLECTION, {
  prefetch: [
    { query: queryVector, using: 'dense', limit: 20 },
    { query: sparseQueryVector, using: 'sparse', limit: 20 },
  ],
  query: { fusion: 'rrf' },
  limit: 3,
  with_payload: true,
})

Two things are worth knowing here. Fusion is a choice, not a default: reciprocal rank fusion combines by rank position and, since 1.17, takes per-ranker weights, while distribution-based score fusion keeps the raw scores and normalizes their distributions first. And prefetches nest, so the same mechanism gives you cheap-candidates-then-expensive-rescore reranking without a second round trip.

The cost is that you own the sparse side. Qdrant does not tokenize your text into a sparse vector for you the way Weaviate's BM25 index does, so you bring a sparse encoder (SPLADE, BM25 as sparse vectors, miniCOIL) and you keep it in sync with your dense model. That is real work, and it buys real control.

The differences that decide it

Who owns the embeddings. Weaviate's vectorizer modules run inside the engine, so a self-hosted instance can take plain text on insert and query and guarantee both sides use the same model. That guarantee is worth more than it sounds: mismatched insert-time and query-time models is one of the most common causes of "our RAG got worse and nobody knows why". Qdrant keeps that in your application, where swapping models is a client-side change and the database never needs to know what you use. Qdrant Cloud will do inference for you, but that is a property of their hosting, not of the engine.

Schema. Qdrant payloads are any JSON at all, which is faster to prototype and has no migration step when the shape changes. Weaviate's typed properties catch errors at insert time and document the data model for whoever maintains it after you. If you would end up enforcing types on your Qdrant payloads in application code anyway, let the database do it.

Filtering. Both pre-filter, meaning the filter constrains the search rather than pruning its results afterwards, which is what keeps a selective filter from returning a nearly empty page. Only the syntax differs. Qdrant uses an Elasticsearch-flavoured structure:

filter: {
  must: [
    { key: 'category', match: { value: 'tech' } },
    { key: 'author', match: { value: 'Sarah Chen' } },
  ],
}

Weaviate uses a builder:

filters: weaviate.filter.and(
  weaviate.filter.byProperty('category').equal('tech'),
  weaviate.filter.byProperty('author').equal('Sarah Chen'),
)

Qdrant composes better for deeply nested conditions. Weaviate reads better for simple ones. Style, not capability.

Multi-tenancy. This is the clearest win on the board and it belongs to Weaviate. Tenants are a first-class concept with activity states: active, inactive, and offloaded to S3 cold storage, so a long tail of dormant customers is not sitting in RAM you are paying for. Weaviate's own docs describe roughly 18,000 to 19,000 active tenants per node in testing. Qdrant does tenancy through payload partitioning: index the tenant field with is_tenant: true and it co-locates that tenant's vectors for sequential reads, optionally with per-tenant HNSW (payload_m) and the global index turned off. It works well and it is more transparent about where data physically sits, which matters for residency requirements. It just has no equivalent of offloading a cold tenant.

Resource footprint. Qdrant is Rust with no garbage collector and generally runs leaner at the same corpus size. Weaviate is Go, efficient but with GC pauses that can show up at high throughput. Do not over-read this. Both handle millions of vectors, and in most applications the embedding call dominates the latency budget, not the search. We size a Qdrant at 512 MB and a Weaviate at 768 MB on our own hosting, which is roughly the gap you should expect. Where the runtime genuinely matters, you are running workload-specific benchmarks anyway, and those beat any general Rust-versus-Go statement.

Managed cloud pricing, checked today

Prices verified on both vendors' own pricing pages on 17 September 2026.

Qdrant Cloud has a free forever single-node cluster at 0.5 vCPU, 1 GB RAM and 4 GB disk, which now includes free cloud inference on selected models. Paid clusters are metered on vCPU, memory and storage, billed hourly, with backup storage on top. Qdrant does not publish per-unit rates on that page and sends you to a calculator, so I am not going to repeat a rate I cannot cite. Premium adds SSO, private VPC links and a 99.9% uptime SLA behind an undisclosed minimum spend. Hybrid Cloud and Private Cloud are quote only.

Weaviate Cloud publishes its rates. The free tier is one cluster per user with 100,000 objects, 1 GB memory, 10 GB disk, and one collection limited to three tenants. Flex starts at $45 a month pay as you go, metering vector dimensions from $0.00465 per million plus storage from $0.12 per GiB. Premium starts at $400 a month on a prepaid contract and drops dimensions to $0.003875 per million shared, or $0.002718 dedicated.

The dimension metric is the one people misread. It scales with vector count multiplied by embedding width, so moving from a 768-dimension model to a 3,072-dimension one quadruples that line without you adding a single document. Qdrant's resource metering has the opposite failure mode: it is predictable per node and opaque until you have modelled it in the calculator.

When to pick Qdrant

• You already have an embedding pipeline and want somewhere fast to put the output.
• You want control over each retrieval stage: your own sparse encoder, your own fusion weights, your own rescoring pass.
• Memory budget matters and you would rather not pay for a garbage collector.
• Your data shape is still moving and a schema migration per change would slow you down.
• You need to know exactly where data physically lives, for residency or audit reasons.

When to pick Weaviate

• Hybrid keyword and semantic ranking is the product, not a component, and you want it in one call.
• You want the engine to own embeddings, including when self-hosted.
• You are building B2B SaaS with many small tenants and want tenant offloading rather than paying to keep everyone hot.
• Multiple people maintain the codebase and typed schemas would act as documentation.
• Your stack already speaks GraphQL.

Where Layerbase fits, and where it does not

Layerbase Cloud runs both engines as ordinary managed databases: Qdrant 1.18 and Weaviate 1.38 today, as HTTPS endpoints that the official clients connect to unchanged with a dashboard-issued API key. Note the version gap against upstream in the table above. We track engine versions on a release cadence rather than same-week, so if you need 1.19 or 1.39 the day it ships, run it yourself or use the vendor cloud.

Both are Performance engines here, so they need the $15/mo Pro plan and stay always on rather than hibernating. A vector database that unloads its HNSW graph and rebuilds it on the next query is not a vector database anyone wants. Pro includes a shared always-on pool of 1.5 GB of RAM and 25 GB of storage across up to 10 databases; a Qdrant draws 512 MB from that pool and a Weaviate draws 768 MB, and more pool costs $10/mo blocks. The price is flat, with no read units, no write units and no per-dimension meter, which is the specific thing usage-metered vector pricing gets wrong when a feature gets popular. Pro comes with a 7-day trial if you want to size it against your own corpus first.

Two things follow from these being normal databases rather than a bespoke vector service. Both branch, so you can fork a populated index into a throwaway copy before a re-embedding experiment and delete it afterwards. Both are reachable over the HTTP query API, so an edge runtime that cannot open a raw socket still works. And because the whole catalogue is 18 engines on one account, the Postgres holding your documents sits in the same dashboard and the same bill as the Qdrant holding their embeddings, which is most of the point if you are assembling the kind of stack in the best database for AI agents.

Where we are the wrong answer: if you need multi-region replication, Weaviate's S3 tenant offloading, managed embedding inference in the database, VPC peering, or an enterprise compliance package, go to Qdrant Cloud or Weaviate Cloud. Those are their products and we do not pretend to match them.

Engine pages and create flows: Qdrant and Weaviate, or straight to create a Qdrant or create a Weaviate. Plans are on pricing.

FAQ

Qdrant or Weaviate: which is better for RAG?

Qdrant in the common case, because a RAG pipeline usually already generates its own embeddings and what it needs is a fast filtered "find items similar to this vector" loop. Weaviate becomes the better answer when retrieval wants keyword matching alongside semantic similarity, or when you would rather not write embedding code at all.

Do both support hybrid search?

Yes, with very different amounts of work. Weaviate fuses BM25 and vector scores in one query with a tunable alpha. Qdrant runs dense and sparse prefetches through the Query API and fuses them with RRF or DBSF, which means you also bring and maintain a sparse encoder. Same capability, different amount of it in your code.

Do I have to generate my own embeddings for Qdrant?

For self-hosted Qdrant, yes. Qdrant Cloud added managed inference with several free models on the free tier and per-token billing beyond that, so the hosted product can embed for you. Weaviate's vectorizer modules live in the engine, so they work self-hosted too.

Which one uses less memory?

Qdrant, generally. It is Rust with no GC and fewer resident structures at the same corpus size, which is why we budget 512 MB for a Qdrant and 768 MB for a Weaviate on our own hosting. Both engines also offer four quantization methods now, and turning on binary or product quantization moves the resident set far more than the language choice does.

Is either one better for multi-tenant SaaS?

Weaviate, clearly. Tenants are first-class, with active, inactive and offloaded states and cold storage on S3, so dormant customers stop costing you RAM. Qdrant does tenancy with payload partitioning and an is_tenant index that co-locates a tenant's vectors, which performs well but keeps everything hot.

Are both actually open source?

Qdrant is Apache-2.0 throughout. Weaviate is BSD-3-Clause except for the wl/ directory in its repository, which carries a separate Weaviate License. For most users that distinction never comes up, but it is worth reading if you plan to fork or redistribute.

Should I use a vector database for full-text search?

Only if semantic similarity is the main product experience. If what you need is typo tolerance, faceting or instant-as-you-type results, a purpose-built engine like Meilisearch is still the better tool. The longer version is in full-text search vs vector search.

Wrapping up

The decision is not really about vector search, because both do that well. It is about how much of the pipeline you want to own. Qdrant hands you the parts and stays out of the way. Weaviate takes the schema, the hybrid ranking, the tenancy, and optionally the embeddings, and asks you to accept its opinions about them.

When you are done locally, clean up:

lbase stop qdrant1
lbase stop weav1
lbase list

Deeper single-engine walkthroughs are in getting started with Qdrant and getting started with Weaviate, and if you are still working out whether you need a dedicated vector store at all, start with what is a vector database.

Create a managed Qdrant or Weaviate on Layerbase Cloud and point your existing client at it.