turbopuffer vs Qdrant
turbopuffer MCP and Qdrant MCP are both official vector-search servers, but they frame an agent's relationship to the database very differently. turbopuffer's server is a builder's companion: it exposes search_docs and an execute tool that runs TypeScript SDK code against your namespaces in a sandbox — so the agent reads turbopuffer's documentation and writes and runs SDK code rather than calling fixed CRUD tools. It is, in effect, a way to develop against turbopuffer from inside an agent. Qdrant's server is a focused semantic-memory layer: just two tools, qdrant-store and qdrant-find, to store information into a collection and retrieve it by meaning, framed as agent memory over a Qdrant instance. So turbopuffer hands the agent a code sandbox plus docs, while Qdrant hands it a clean store-and-retrieve memory abstraction. Here is a balanced look at how they differ.
How they compare
| Dimension | turbopuffer | Qdrant |
|---|---|---|
| Interaction style | Code-first: the agent reads docs (search_docs) and runs TypeScript SDK code via an execute tool in a sandbox. | Fixed tools: qdrant-store and qdrant-find provide a simple store-and-retrieve interface — no code writing needed. |
| Flexibility vs simplicity | Highly flexible — anything the SDK can do, the agent can express in code — at the cost of writing and running code. | Deliberately minimal — two tools framed as semantic memory, easy to reason about and hard to misuse. |
| Primary intent | Helping a developer build on turbopuffer: explore the docs and prototype SDK calls against real namespaces. | Giving an agent a semantic-memory store it reads from and writes to over a single collection. |
| Setup | Runs over stdio via npx (@turbopuffer/turbopuffer-mcp); the execute tool targets your namespaces in a sandbox. | Runs over stdio via uvx (mcp-server-qdrant); set a collection name and a Qdrant URL or local path. |
| Best-fit task | Developing and prototyping against turbopuffer — running SDK code and consulting docs from inside an agent. | Adding a straightforward semantic-memory layer to an agent with minimal moving parts. |
Verdict
Both are official, but they answer different questions, so choose by intent. Pick turbopuffer's server when you are building on turbopuffer and want an agent that can read the docs and run TypeScript SDK code against your namespaces in a sandbox — maximum flexibility for development and prototyping. Pick Qdrant's server when you want a clean semantic-memory abstraction: two tools, store and find, that let an agent remember and recall information over a collection with little to configure. In short: turbopuffer for code-first development against a vector store; Qdrant for a simple, hard-to-misuse semantic-memory layer.
FAQ
- Why does turbopuffer's server run code instead of offering store/find tools?
- Its server is designed as a builder's companion: rather than fixed CRUD tools, it gives the agent the docs (search_docs) and an execute tool that runs TypeScript SDK code in a sandbox. That makes it flexible for development, where you may need any SDK operation, not just store-and-retrieve.
- Which is simpler to use as agent memory?
- Qdrant's server, by far. Its two tools — qdrant-store and qdrant-find — present a clean semantic-memory abstraction with nothing to code. turbopuffer's code-first execute model is more powerful but requires the agent to write and run SDK code rather than call a simple store/retrieve interface.