Migrate Pinecone to Qdrant: Complete Migration Guide | Zero Heart Burns

A new migration guide from Qdrant outlines how to move from Pinecone to Qdrant, citing Pinecone's lack of an export API, 40KB metadata limit, and 100,000 namespace cap as key pain points. The guide notes that Pinecone is SaaS-only with no self-hosting option, while Qdrant can be run locally via Docker, and warns that Pinecone rescales cosine similarity to [0, 1] whereas Qdrant returns [-1, 1].

Okay so… you opened a bill from Pinecone and did a double-take. Or you tried to self-host it and discovered that’s just not a thing Pinecone lets you do. Or maybe you hit the 40KB metadata limit mid-sprint and your whole architecture needed a rethink. Whatever the reason might be you’re here, you want to move your vectors, and you want to do it without a disaster. I’ve been through this migration. Here’s everything I wish someone had told me before I started. Here’s the thing about Pinecone… it’s genuinely easy to get started with. The docs are everywhere in AI tutorials, the API is clean, and you can have vectors in the cloud in like 20 minutes. That’s why so many teams start there. But then production hits… The cost curve surprises you. Pinecone’s serverless model charges per read unit, so every query costs money. At moderate QPS say 500 queries per second , that meter is spinning fast. One team I talked to went from a comfortable $200/month in early testing to over $2k/month once their app got traction. The data doesn’t really get bigger, but the bills do. Vendor lock-in is real. Here’s a thing that quietly terrifies me: Pinecone has no export API. Like, none. You cannot say “give me all my vectors as a file.” If you want your data back, you have to iterate through IDs and fetch them back one batch at a time, and that only works on serverless indexes. Pod-based indexes? No list API at all. Pretty wild right? Namespace limits sneak up on you. Pinecone namespaces are a nice partitioning primitive but you’re capped at 100,000 namespaces on Standard. If you’re building a multi-tenant SaaS where each user has their own vector space… yeah, that can get uncomfortable fast. Metadata is flat and limited. 40KB per record, no nested JSON, no geo-coordinates, no full-text search on metadata fields. Need to store a document’s full text alongside its embedding? You’ll be doing a lot of creative truncation. No self-hosting, ever. This one is fundamental. Pinecone is SaaS-only. There is no Docker image, no Kubernetes operator, no “run it on your own machine” option. For teams with data residency requirements, regulated industries, or just a preference for not being dependent on external infrastructure… this is a hard blocker. The lightbulb moment for most developers is when they run Qdrant http://qdrant.tech/?utm medium=referral&utm source=stars&utm campaign=devrel&utm content=niranjan-akella locally with docker run -p 6333:6333 qdrant/qdrant and realize it's the same thing - same API, same capabilities, same performance - but it's just... there, on your machine, completely under your control. Here’s the shape of this migration so you know what you’re getting into: Nothing here is magic. It’s just a bit of Python and some patience. Before touching any code, let’s map the concepts. This is reference material to skim it now, come back when something breaks. The namespace decision is actually important. You have two options: For most Pinecone migrations I’d go with option B payload field , because collections have a recommended cap around 1,000 in Qdrant, and many Pinecone users have way more namespaces than that. php Pinecone metric values - Qdrant Distance enumMETRIC MAP = { "cosine": Distance.COSINE, "euclidean": Distance.EUCLID, "dotproduct": Distance.DOT,} Qdrant also has Distance.MANHATTAN - no Pinecone equivalent One gotcha here: Pinecone rescales cosine similarity to 0, 1 . Qdrant returns -1, 1 . The rankings are identical, but any code that thresholds on raw score values will behave differently. Keep this in mind when you port your search logic. === PINECONE ===results = index.query vector= 0.1 1536, filter={ "$and": {"genre": {"$eq": "sci-fi"}}, {"year": {"$gte": 2020}}, {"tags": {"$in": "ai", "robots" }} }, top k=10, namespace="my-namespace", include metadata=True matches = results "matches" list of {id, score, metadata} === QDRANT ===from qdrant client.models import Filter, FieldCondition, MatchValue, MatchAny, Rangeresults = client.search collection name="my collection", query vector= 0.1 1536, query filter=Filter must= FieldCondition key="genre", match=MatchValue value="sci-fi" , FieldCondition key="year", range=Range gte=2020 , FieldCondition key="tags", match=MatchAny any= "ai", "robots" , If you're using the payload-field namespace strategy: FieldCondition key=" namespace", match=MatchValue value="my-namespace" , , limit=10, with payload=True results is a list of ScoredPoint objects with .id, .score, .payload The filter mapping rule of thumb: $and maps to must, $or maps to should, $ne maps to must not. Numeric ranges map directly. $in maps to MatchAny. Honestly pretty intuitive once you see it side by side. Pinecone hybrid search uses a single alpha parameter 0 = pure sparse, 1 = pure dense, linear blend . Qdrant uses explicit prefetch legs and rank fusion - either RRF Reciprocal Rank Fusion or DBSF. More code to write, but dramatically more control over how the fusion behaves. You can weight each leg independently, which ends up being pretty important for production tuning. Here’s the honest truth: Pinecone has no export feature. No “Download All Data” button, no export endpoint, no snapshot you can take away. The only way out is to iterate through vector IDs and fetch them back in batches. The approach: One more thing before the code: this only works on serverless indexes . Pod-based indexes have no list API at all. If you're on a pod-based index... the only real option is to re-embed from your original document source, because there's no supported way to bulk-export from a pod index. Yikes. Rate limits to know: list is 200 req/s, fetch is 100 req/s. With 1,000 IDs per fetch call, that's theoretically 100,000 vectors per second. In practice, you'll be slower because of network and parsing overhead - but you won't hit limits if you stay around 10 concurrent fetch calls. Here’s a complete, resumable Pinecone exporter: bash /usr/bin/env python3 VIBE CODED for smooth and quick setups"""pinecone dumper.pyExports all vectors from a Pinecone serverless index to a JSONL file.Resumable: if interrupted, just rerun - it will pick up from where it left off.Requirements: pip install pinecone =3.0.0 tqdmUsage: python pinecone dumper.py \ --api-key pcsk XXX \ --index-name my-index \ --output vectors.jsonl"""import argparseimport jsonimport osimport timeimport mathimport picklefrom pathlib import Pathfrom pinecone import Pineconefrom tqdm import tqdmLIST BATCH SIZE = 100 Pinecone max IDs per list pageFETCH BATCH SIZE = 1000 Pinecone max IDs per fetch callFETCH RATE SLEEP = 0.011 ~90 req/s, safely under 100 req/s limitdef load checkpoint ckpt path: str - dict: if Path ckpt path .exists : with open ckpt path, "rb" as f: return pickle.load f return {}def save checkpoint ckpt path: str, data: dict : tmp = ckpt path + ".tmp" with open tmp, "wb" as f: pickle.dump data, f os.replace tmp, ckpt path def list all ids index, namespace: str, checkpoint: dict, ckpt path: str - list: ckpt key = f"ids:{namespace}" if ckpt key in checkpoint: print f" Resuming ID listing for namespace='{namespace}' from checkpoint..." return checkpoint ckpt key all ids = cursor = None page num = 0 print f" Listing IDs for namespace='{namespace}'..." while True: kwargs = {"limit": LIST BATCH SIZE, "namespace": namespace} if cursor: kwargs "pagination token" = cursor try: resp = index.list paginated kwargs except Exception as e: print f" ERROR listing page {page num}: {e}. Retrying in 5s..." time.sleep 5 continue page ids = v.id for v in resp.vectors or all ids.extend page ids page num += 1 if page num % 100 == 0: print f" ... {len all ids :,} IDs listed so far" cursor = resp.pagination.next if resp.pagination else None if not cursor: break print f" Found {len all ids :,} IDs in namespace='{namespace}'" checkpoint ckpt key = all ids save checkpoint ckpt path, checkpoint return all idsdef fetch and write index, all ids, namespace, output file, checkpoint, ckpt path : ckpt key = f"fetched batches:{namespace}" completed batches = checkpoint.get ckpt key, set total batches = math.ceil len all ids / FETCH BATCH SIZE new writes = 0 with tqdm total=len all ids , desc=f" Fetching vectors ns='{namespace}' " as pbar: for batch idx in range total batches : start = batch idx FETCH BATCH SIZE batch ids = all ids start:start + FETCH BATCH SIZE if batch idx in completed batches: pbar.update len batch ids continue Fetch with exponential backoff retry for attempt in range 5 : try: resp = index.fetch ids=batch ids, namespace=namespace break except Exception as e: wait = 2 attempt print f"\n Fetch attempt {attempt+1} failed: {e}. Waiting {wait}s..." time.sleep wait else: print f"\n ERROR: Could not fetch batch {batch idx}. Skipping." pbar.update len batch ids continue vectors map = resp.get "vectors", {} for pid, pdata in vectors map.items : record = { "id": pid, "values": pdata.get "values", , "metadata": pdata.get "metadata", {} , " namespace": namespace, } sv = pdata.get "sparse values" or pdata.get "sparseValues" if sv: record "sparse values" = { "indices": sv.get "indices", , "values": sv.get "values", , } output file.write json.dumps record + "\n" new writes += 1 completed batches.add batch idx if batch idx % 10 == 0: checkpoint ckpt key = completed batches save checkpoint ckpt path, checkpoint pbar.update len batch ids time.sleep FETCH RATE SLEEP checkpoint ckpt key = completed batches save checkpoint ckpt path, checkpoint return new writesdef main : parser = argparse.ArgumentParser description="Export Pinecone index to JSONL" parser.add argument "--api-key", required=True parser.add argument "--index-name", required=True parser.add argument "--index-host", default=None, help="Index host URL optional, faster " parser.add argument "--namespace", default=None, help="Export one namespace only" parser.add argument "--output", default="pinecone export.jsonl" parser.add argument "--checkpoint", default="pinecone dump checkpoint.pkl" parser.add argument "--fresh", action="store true", help="Ignore existing checkpoint" args = parser.parse args pc = Pinecone api key=args.api key index = pc.Index host=args.index host if args.index host else pc.Index args.index name stats = index.describe index stats namespaces = list stats.get "namespaces", {} .keys if not namespaces: namespaces = "" default namespace if args.namespace: namespaces = args.namespace total vectors = stats.get "total vector count", 0 dimension = stats.get "dimension", "unknown" print f"\nIndex: {args.index name}" print f" Dimension: {dimension}" print f" Total vectors: {total vectors:,}" print f" Namespaces: {namespaces}" print f" Output: {args.output}\n" checkpoint = {} if args.fresh else load checkpoint args.checkpoint total written = 0 with open args.output, "a", encoding="utf-8" as out f: for ns in namespaces: print f"Exporting namespace='{ns}'..." ids = list all ids index, ns, checkpoint, args.checkpoint written = fetch and write index, ids, ns, out f, checkpoint, args.checkpoint total written += written print f" Done. {written:,} vectors written.\n" print f"Export complete Total: {total written:,} vectors - {args.output}" print f"\nNext step: python qdrant uploader.py --input {args.output}" if name == " main ": main Run it like this: pip install "pinecone =3.0.0" tqdmpython pinecone dumper.py \ --api-key pcsk YOUR KEY \ --index-name my-index \ --output my vectors.jsonl If it gets interrupted mid-run, just run it again …. it’ll skip everything it already fetched. The checkpoint file tracks progress at the batch level so you don’t re-fetch things you already have. For very large indexes 100M+ vectors , this will take a while. The math: at 1,000 vectors per fetch and ~90 requests per second, you’re looking at roughly 90,000 vectors per second throughput. 100M vectors = ~18 minutes of pure fetch time, plus listing time on top. Run it overnight. Okay, you’ve got your my vectors.jsonl file. Now let's get it into Qdrant. Step 1: Start Qdrant locally docker run -d --name qdrant \ -p 6333:6333 -p 6334:6334 \ -v $ pwd /qdrant storage:/qdrant/storage \ qdrant/qdrant The web UI is at http://localhost:6333/dashboard. It's actually quite nice - you can browse collections, run test queries, inspect points. Better than nothing Step 2: Recreate your collection You need the dimension and metric from your Pinecone index. The describe index stats call doesn't return the metric annoyingly - check your index creation code or the Pinecone console. python from qdrant client import QdrantClientfrom qdrant client.models import Distance, VectorParams, SparseVectorParams, HnswConfigDiff, OptimizersConfigDiff client = QdrantClient url="http://localhost:6333" For Qdrant Cloud: client = QdrantClient url="https://YOUR-CLUSTER.cloud.qdrant.io", api key="YOUR QDRANT API KEY" COLLECTION = "my collection"DIMENSION = 1536 match your Pinecone index dimensionMETRIC = "cosine"METRIC MAP = { "cosine": Distance.COSINE, "euclidean": Distance.EUCLID, "dotproduct": Distance.DOT,} Disable HNSW during bulk load - re-enable after 3-5x faster ingest client.create collection collection name=COLLECTION, vectors config=VectorParams size=DIMENSION, distance=METRIC MAP METRIC , optimizers config=OptimizersConfigDiff indexing threshold=0 , print f"Created collection '{COLLECTION}'" Notice indexing threshold=0 - that disables HNSW index building during the bulk load. We'll re-enable it after. This makes loading 3-5x faster because Qdrant isn't trying to build the graph while you're flooding it with vectors. Step 3: The uploader script bash /usr/bin/env python3 Once again, have vibe coded this part to perfection """qdrant uploader.pyReads a JSONL file from pinecone dumper.py and bulk-upserts into Qdrant.Handles ID translation, batching, retries, and progress tracking.Requirements: pip install "qdrant-client =1.9.0" tqdmUsage: python qdrant uploader.py \ --input vectors.jsonl \ --collection my collection \ --qdrant-url http://localhost:6333"""import argparseimport jsonimport hashlibimport timefrom pathlib import Pathfrom qdrant client import QdrantClientfrom qdrant client.models import PointStruct, SparseVector, Distance, VectorParams, OptimizersConfigDiff, UpdateStatus from tqdm import tqdmUPSERT BATCH SIZE = 512 256-512 is the sweet spotMAX RETRIES = 5def pinecone id to qdrant pinecone id: str - str: """ Convert a Pinecone string ID to a deterministic UUID for Qdrant. We store the original ID in payload as pinecone id for reverse lookup. """ h = hashlib.sha256 pinecone id.encode .hexdigest return f"{h :8 }-{h 8:12 }-{h 12:16 }-{h 16:20 }-{h 20:32 }"def count lines filepath: str - int: count = 0 with open filepath, "rb" as f: for in f: count += 1 return countdef upsert batch with retry client, collection, points, max retries=MAX RETRIES : for attempt in range max retries : try: result = client.upsert collection name=collection, points=points, wait=True, return result.status == UpdateStatus.COMPLETED except Exception as e: wait = 2 attempt print f"\n Upsert attempt {attempt+1} failed: {e}. Waiting {wait}s..." time.sleep wait print f"\n ERROR: Batch failed after {max retries} retries. Skipping {len points } points." return Falsedef build point record: dict, has sparse: bool - PointStruct: pinecone id = record "id" qdrant id = pinecone id to qdrant pinecone id values = record.get "values", payload = dict record.get "metadata", {} payload " pinecone id" = pinecone id payload " namespace" = record.get " namespace", "" if has sparse and "sparse values" in record: sv = record "sparse values" vector = { "dense": values, "sparse": SparseVector indices=sv.get "indices", , values=sv.get "values", } else: vector = values return PointStruct id=qdrant id, vector=vector, payload=payload def main : parser = argparse.ArgumentParser description="Upload JSONL to Qdrant" parser.add argument "--input", required=True parser.add argument "--collection", required=True parser.add argument "--qdrant-url", default="http://localhost:6333" parser.add argument "--api-key", default=None, help="Qdrant API key for cloud " parser.add argument "--has-sparse", action="store true" parser.add argument "--batch-size", type=int, default=UPSERT BATCH SIZE args = parser.parse args client = QdrantClient url=args.qdrant url, api key=args.api key try: info = client.get collection args.collection print f"Collection '{args.collection}' found - {info.vectors count or 0:,} existing vectors" except Exception: print f"ERROR: Collection '{args.collection}' not found. Create it first." return total lines = count lines args.input print f"\nInput file: {args.input} {total lines:,} records " print f"Batch size: {args.batch size}\n" batch = total uploaded = 0 total failed = 0 with open args.input, "r", encoding="utf-8" as f, \ tqdm total=total lines, desc="Uploading", unit="vec" as pbar: for line in f: line = line.strip if not line: continue try: record = json.loads line except json.JSONDecodeError as e: print f"\n Bad JSON line: {e}. Skipping." pbar.update 1 continue batch.append build point record, args.has sparse if len batch = args.batch size: ok = upsert batch with retry client, args.collection, batch if ok: total uploaded += len batch else: total failed += len batch pbar.update len batch batch = if batch: ok = upsert batch with retry client, args.collection, batch total uploaded += len batch if ok else 0 total failed += len batch if not ok else 0 pbar.update len batch print f"\nUpload complete Uploaded: {total uploaded:,} Failed: {total failed:,}" Re-enable HNSW indexing now that bulk load is done print "\nRe-enabling HNSW indexing..." client.update collection collection name=args.collection, optimizers config=OptimizersConfigDiff indexing threshold=20 000 , print "Waiting for index to build this may take a few minutes ..." while True: info = client.get collection args.collection status = str info.status .lower if "green" in status: break print f" Status: {status}... waiting 15s" time.sleep 15 final count = client.get collection args.collection .vectors count print f"\nCollection '{args.collection}' is ready Vector count: {final count:,}" if name == " main ": main Run the full pipeline: pip install "qdrant-client =1.9.0" tqdm 1. Export from Pineconepython pinecone dumper.py --api-key pcsk XXX --index-name my-index --output vectors.jsonl 2. Upload to local Qdrantpython qdrant uploader.py \ --input vectors.jsonl \ --collection my collection \ --qdrant-url http://localhost:6333 For Qdrant Cloud : sign up here https://cloud.qdrant.io/signup?utm medium=referral&utm source=stars&utm campaign=devrel&utm content=niranjan-akella , create a cluster the free tier gets you 1M vectors permanently , then use: python qdrant uploader.py \ --input vectors.jsonl \ --collection my collection \ --qdrant-url https://YOUR-CLUSTER.cloud.qdrant.io \ --api-key YOUR QDRANT KEY Step 4: Verify it worked python from qdrant client import QdrantClientclient = QdrantClient url="http://localhost:6333" Exact count Qdrant's vectors count is approximate for large collections def exact count client, collection : count, offset = 0, None while True: recs, next offset = client.scroll collection name=collection, limit=1000, offset=offset, with payload=False, with vectors=False count += len recs offset = next offset if offset is None: break return countn = exact count client, "my collection" print f"Qdrant has {n:,} vectors" Spot-check: search and print original Pinecone IDs from payloadtest vec = 0.1 1536 replace with a real vectorresults = client.search "my collection", query vector=test vec, limit=5, with payload=True for r in results: print f" score={r.score:.4f} original pinecone id={r.payload.get ' pinecone id' }" One more option: Qdrant’s official migration tool Qdrant ships a Docker-based migration CLI that handles Pinecone directly. For serverless indexes, one command does the whole thing: docker run --rm -it registry.cloud.qdrant.io/library/qdrant-migration pinecone \ --pinecone.index-host 'https://your-index.svc.pinecone.io' \ --pinecone.index-name 'your-index' \ --pinecone.api-key 'pcsk ...' \ --qdrant.url 'https://your-cluster.cloud.qdrant.io:6334' \ --qdrant.api-key 'your-qdrant-key' \ --qdrant.collection 'your-collection' \ --migration.batch-size 64 Note the gRPC port 6334 : the migration tool uses gRPC, not the REST API. And it’s resumable via an internal migration offsets collection it creates on the target. If it gets killed, just rerun and it picks up from the last offset. If you’re running a live production service on Pinecone, you can’t just turn it off run the migration and turn it back on. Here’s how to do it with zero downtime. The core idea: run both databases simultaneously. Pinecone stays primary for reads. Qdrant gets all the writes. Once Qdrant has all the historical data and has proven itself with real traffic, you flip the switch. python import threadingfrom concurrent.futures import ThreadPoolExecutorfrom queue import Queue, Emptyclass DualWriteClient: """ Wrap your existing Pinecone index to simultaneously write to Qdrant. Pinecone is primary writes block on Pinecone success . Qdrant writes are async and non-blocking - failures queue for retry. """ def init self, pinecone idx, qdrant client, qdrant collection : self.pine = pinecone idx self.qdrant = qdrant client self.col = qdrant collection self.pool = ThreadPoolExecutor max workers=4, thread name prefix="qdrant-write" self.retry q = Queue maxsize=10 000 self. start retry worker def upsert self, vectors, namespace="" : Step 1: Write to Pinecone primary, blocks until confirmed self.pine.upsert vectors=vectors, namespace=namespace Step 2: Write to Qdrant async never blocks your app self.pool.submit self. qdrant upsert, vectors, namespace def qdrant upsert self, vectors, namespace : from qdrant client.models import PointStruct points = PointStruct id=pinecone id to qdrant v "id" , vector=v "values" , payload={ v.get "metadata", {} , " pinecone id": v "id" , " namespace": namespace} for v in vectors try: self.qdrant.upsert collection name=self.col, points=points, wait=True except Exception as e: print f"Qdrant write failed, queuing retry: {e}" try: self.retry q.put nowait "upsert", points except Exception: print f"Retry queue full - {len points } points dropped" def delete self, ids, namespace="" : self.pine.delete ids=ids, namespace=namespace qdrant ids = pinecone id to qdrant i for i in ids self.pool.submit self. qdrant delete, qdrant ids def qdrant delete self, ids : try: self.qdrant.delete collection name=self.col, points selector=ids, wait=True except Exception as e: try: self.retry q.put nowait "delete", ids except Exception: pass def start retry worker self : t = threading.Thread target=self. retry loop, daemon=True t.start def retry loop self : while True: try: op, payload = self.retry q.get timeout=5 except Empty: continue for attempt in range 5 : try: if op == "upsert": self.qdrant.upsert collection name=self.col, points=payload, wait=True else: self.qdrant.delete collection name=self.col, points selector=payload, wait=True break except Exception: time.sleep 2 attempt Usage: replace your existing pinecone index with this one line Before: results = pinecone index.query ... After: results = dual client.pine.query ... <- reads still go to Pinecone dual client = DualWriteClient pc.Index "my-index" , qdrant client, "my collection" dual client.upsert vectors= ... <- writes go to both Once dual-write is running, here’s the sequence: Before you switch traffic to Qdrant: JUST VERI FY the following okay? x Dual-write has been running = 48 hours without errors x Backfill complete - Qdrant vector count within 0.1% of Pinecone count x Shadow comparison: mean Recall@10 = 0.95 over at least 10,000 queries x Qdrant collection status = green fully indexed x P99 search latency on Qdrant within 15% of Pinecone x Rollback plan tested - know how to re-enable Pinecone reads in under 5 minutes Qdrant has collection aliases so that a single API call switches an alias from one collection to another with zero gap. Use this for the cutover: python from qdrant client.models import CreateAliasOperation, DeleteAliasOperation One API call - no window where the alias is undefinedqdrant client.update collection aliases change aliases operations= DeleteAliasOperation delete alias={"alias name": "production"} , CreateAliasOperation create alias={ "collection name": "my collection", "alias name": "production" } , From this point: all reads going to "production" alias hit Qdrant Keep dual-write running for at least 48 hours after full cutover. If something goes wrong, rollback is literally just updating a feature flag or load balancer weight to send reads back to Pinecone. Since dual-write is still active, Pinecone stays in sync during that window. Rolling back is instant and safe. Okay… so I’ve been pretty technical so far. Let me just talk about what actually feels different when you’re using Qdrant versus Pinecone day-to-day. The free tier is actually useful. Qdrant Cloud’s https://cloud.qdrant.io/signup?utm medium=referral&utm source=stars&utm campaign=devrel&utm content=niranjan-akella free tier is permanent and not a trial, and supports roughly 1M vectors on a real cluster 0.5 vCPU, 1 GB RAM, 4 GB disk Pinecone’s free tier is 100,000 vectors on a single serverless index with the per-read-unit billing lurking. Qdrant’s free tier is just… a free cluster. No gotchas, no time limit. NOTABLE MENTIONS FROM MY RESEARCH AND DUMP BELOW You can actually run it yourself. docker run -p 6333:6333 qdrant/qdrant. That's it. The self-hosted version and the cloud version run the same binary. No features are gated behind cloud-only access. The API is identical everywhere. You can move between local development, your own Kubernetes cluster, and Qdrant Cloud at any time. Your data is portable. Your skills transfer. Pinecone is SaaS-only, period. Quantization is a superpower. Pinecone stores everything as float32. That’s 4 bytes per dimension, no exceptions. For a 10M vector / 1536-dim collection, that’s ~61 GB of raw vector data. With Qdrant’s Turbo4 4-bit datatype from v1.19 , you get that down to ~7.6 GB while maintaining solid recall. With binary quantization you’re under 2 GB. This is roughly a 30x memory reduction. At $5/GB/month in cloud RAM costs, that’s a very large number. Quick cost comparison for 10M vectors at 1536 dims Filterable HNSW is a real algorithmic difference. Pinecone applies filters as pre-filter or post-filter. If your filter is very selective say, filter to 1% of vectors , post-filtering wastes a huge amount of graph traversal work, and pre-filtering with very small candidate sets loses recall. Qdrant integrates payload filtering directly into the HNSW graph traversal — it navigates the graph while respecting the filter in real-time. This gives predictable recall even on highly selective filters. It’s not a marketing claim — it’s a fundamentally different query execution model. Multi-vector per point. Each Qdrant point can have multiple named vectors. One point can carry a text embedding 768-dim , an image embedding 512-dim , and a sparse BM25 vector, all stored together with their payload. A single hybrid search can fuse all three with RRF. Pinecone gives you one vector per record. Full stop. This matters a lot for multimodal and hybrid retrieval workloads. Data portability is the anti-vendor-lock-in story. With Qdrant, you can snapshot any collection and download it: Create a snapshotsnapshot info = client.create snapshot collection name="my collection" print f"Snapshot: {snapshot info.name}" Download it it's just an HTTP GET GET /collections/my collection/snapshots/{snapshot name} That snapshot is your data. You can restore it to any Qdrant instance anywhere. If Qdrant doubles their prices tomorrow, you have a complete copy of your data ready to move. With Pinecone, you do the LIST+FETCH dance described in Section 3. If Pinecone has an outage and you can’t list your IDs… well. Open source, for real. Qdrant has 34,000+ GitHub stars, Apache 2.0 license, and the team actively responds to issues. You can read the source code, understand exactly what’s happening with your data, file bugs, send PRs. When something weird happens with your search results, you can actually dig in and find out why. Pinecone is a black box. That distinction sounds abstract until something goes wrong. The Qdrant documentation https://qdrant.tech/documentation/?utm medium=referral&utm source=stars&utm campaign=devrel&utm content=niranjan-akella covers all of this in depth — quantization options, memory tier configs, distributed deployment, the lot. And if you want to follow what’s coming next new quantization research, benchmark results, engineering deep-dives , the newsletter https://qdrant.tech/subscribe/?utm medium=referral&utm source=stars&utm campaign=devrel&utm content=niranjan-akella is worth subscribing to. They publish real engineering content, not just product announcements. Alright now that’s the full picture. The migration is doable okay and most teams do it over a week or two with zero downtime using the dual-write approach. The scripts handle the heavy lifting. The main gotchas to keep in mind: Good luck with the migration. You’ve got this. Migrate Pinecone to Qdrant: Complete Migration Guide | Zero Heart Burns https://pub.towardsai.net/migrate-pinecone-to-qdrant-complete-migration-guide-zero-heart-burns-b8ba3cbbfd12 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.