Does txtfetch connect directly to pgvector, Pinecone, Qdrant, Chroma, or Weaviate?

No. txtfetch ships no connector, plugin, or client for any of the five. It returns extracted text over one HTTP call. Chunking, embedding, and the write step stay yours, using each store's own client.

Which store should I pick?

It depends on what you already run. Already on Postgres? pgvector adds a column type, not a new service. Want fully managed with no ops? Pinecone or Weaviate Cloud. Want open source you can also self-host? Qdrant or Chroma. Each spoke names its own real constraints.

Why does this page focus on constraints instead of features?

Chunking happens before the write, not after. A metadata ceiling, an ID format rule, or a batch limit changes how you chunk and what you can store. That matters more to this pipeline than a feature list would.

Does txtfetch benchmark accuracy, speed, or recall for any of these stores?

No. None of these five is a text-extraction service, so there's no such comparison to make here. See /benchmarks for txtfetch's own measured extraction numbers.

Extract text into a vector store

The four steps, one pipeline

A document goes in, and a row in a vector store comes out. txtfetch owns the first step. You own the rest, and each store below changes what "the rest" looks like.

Extract. One HTTP call turns the file or URL into plain text.
Chunk. Split the text into pieces sized for retrieval, not for a limit.
Embed. Turn each chunk into a vector with the embedding model you already run.
Upsert. Write the vector, its metadata, and often the chunk text, to the store.

the five-way matrix

pgvector, Pinecone, Qdrant, Chroma, and Weaviate, compared on what the write step needs
Constraint	pgvector	Pinecone	Qdrant	Chroma	Weaviate
Per-vector metadata limit	None from pgvector itself. You're bound by ordinary Postgres limits: up to 1 GB per field, with TOAST moving large text out of the row automatically.	40 KB per vector, filterable fields only. Values must be a string, number, boolean, or list of strings. No nested objects.	No fixed cap on a point's payload. Bound by the request-size ceiling instead: 32 MB per REST call by default, or a much smaller 4 MB default on the gRPC client unless you raise it.	No published byte ceiling on a document or metadata value.	No published per-property byte ceiling. Bound by the overall request size, mostly relevant over gRPC.
Stores the chunk text itself	Yes. The chunk text is just another column in the same table as the vector.	Not as a dedicated field. Put the chunk text in metadata, inside that 40 KB, or keep it in your own store, keyed by the vector id.	Yes. The payload is arbitrary JSON stored with the point, so the chunk text is a normal payload field.	Yes, as a dedicated documents field, alongside embeddings and metadatas.	Yes. The chunk text is an ordinary schema property, for example content, on the same object as the vector.
ID format	None. Use whatever primary key type the table declares: bigserial, uuid, or text.	An ASCII string, 1 to 512 characters.	An unsigned 64-bit integer or a UUID string. No other string is accepted.	Any unique string within the collection.	A UUID. Weaviate can generate one deterministically from your own fields with generate_uuid5(...) if you don't supply one.
Max vector dimensions	16,000 for a plain vector column. Building an HNSW or IVFFlat index on it caps out at 2,000 dimensions, or 4,000 for a halfvec column.	20,000 dimensions per vector.	65,535 dimensions for a dense vector.	No published ceiling. The first vector you insert fixes the collection's dimension, and every later insert must match it.	65,535 dimensions, stored as a uint16 index. Memory runs out long before that ceiling matters.
Batch upsert size	None from pgvector. You're bound by ordinary Postgres statement size. Use COPY for a bulk load.	2 MB per upsert request. Pinecone's own guidance keeps a single call near 1,000 vectors, fewer at higher dimensions.	No hard point-count cap. Qdrant's own guidance suggests 64 to 256 points per batch, with a few parallel upload threads for a big job.	Governed by client.get_max_batch_size(), a SQLite parameter ceiling that varies by build (roughly 5,000 to 44,000 records). Chroma won't split an oversized call for you.	No fixed cap. collection.data.insert_many(...) batches server-side, so you don't tune a batch size by hand.
Index type	Exact scan with no index, IVFFlat, or HNSW. HNSW is the common default today.	Serverless indexes only today. Metric is cosine, dotproduct, or euclidean, set once at index creation.	HNSW, with optional scalar or binary quantization to cut memory use.	HNSW. Distance metric (l2, cosine, or ip) is set once at collection creation and can't change after.	HNSW by default, with flat, dynamic, and hfresh alternatives, plus PQ, BQ, SQ, and RQ quantization.

Full citations, dated, live on each spoke below. No row states an accuracy, speed, or recall figure. See /benchmarks for txtfetch's own numbers.

No connector ships for any of them

txtfetch ships no plugin or client for pgvector, Pinecone, Qdrant, Chroma, or Weaviate. Each spoke below shows the whole integration. Extract with txtfetch, then write to the store with its own client, the same way you would for any other source of text.

pick a destination

pgvector

A Postgres extension that adds a vector column type to a database you already run.

Exact scan with no index, IVFFlat, or HNSW. HNSW is the common default today.

Pinecone

A managed, serverless vector database with a hard ceiling on per-vector metadata.

Serverless indexes only today. Metric is cosine, dotproduct, or euclidean, set once at index creation.

Qdrant

An open-source and managed vector database with a strict, easy-to-miss ID format.

HNSW, with optional scalar or binary quantization to cut memory use.

Chroma

An open-source embedding database with a first-class field for the chunk text itself.

HNSW. Distance metric (l2, cosine, or ip) is set once at collection creation and can't change after.

Weaviate

An open-source and managed vector database whose client API renamed its own core method this year.

HNSW by default, with flat, dynamic, and hfresh alternatives, plus PQ, BQ, SQ, and RQ quantization.

More on this pipeline

RAG & LLM ingestion — the wider use case this pipeline feeds.
RAG recipe: chunk, embed, index — the same pipeline through LangChain or LlamaIndex instead of plain Python.
Chunk previewer — test your own extracted text before you write the first row.

frequently asked questions

Does txtfetch connect directly to pgvector, Pinecone, Qdrant, Chroma, or Weaviate?: No. txtfetch ships no connector, plugin, or client for any of the five. It returns extracted text over one HTTP call. Chunking, embedding, and the write step stay yours, using each store's own client.
Which store should I pick?: It depends on what you already run. Already on Postgres? pgvector adds a column type, not a new service. Want fully managed with no ops? Pinecone or Weaviate Cloud. Want open source you can also self-host? Qdrant or Chroma. Each spoke names its own real constraints.
Why does this page focus on constraints instead of features?: Chunking happens before the write, not after. A metadata ceiling, an ID format rule, or a batch limit changes how you chunk and what you can store. That matters more to this pipeline than a feature list would.
Does txtfetch benchmark accuracy, speed, or recall for any of these stores?: No. None of these five is a text-extraction service, so there's no such comparison to make here. See /benchmarks for txtfetch's own measured extraction numbers.

Wire the extraction step in.

The RAG recipe shows the whole path, from a file to the vector store upsert.

Read the RAG recipe →

Get an API key →

txtfetch gets you the text. Here's the rest of the pipeline.

The four steps, one pipeline

No connector ships for any of them

More on this pipeline

Wire the extraction step in.