turbopuffer vs Weaviate
turbopuffer and Weaviate are both vector-search databases with official MCP servers, but they hand an agent very different shapes of tool. turbopuffer is a serverless vector and full-text search database built on object storage, and its server takes a copilot-for-building stance: rather than wrapping each REST endpoint, it gives the agent two high-leverage tools — a documentation search to ground answers in current guidance, and a code-execution tool that writes TypeScript against the official turbopuffer SDK and runs it in an isolated sandbox, so the agent can list namespaces, write and query documents, inspect schema, and tune recall by actually exercising the SDK. Weaviate ships its MCP server built directly into the database engine (as of 1.37.1, enabled with a feature flag on the same port as the REST API), exposing a small set of retrieval tools: inspect a collection's schema and vectorizer config, list tenants in a multi-tenant collection, run a hybrid query fusing vector similarity with BM25 keyword matching, and upsert objects. So one is an SDK-driven build copilot, the other a built-in retrieval surface. Here is how they compare.
How they compare
| Dimension | turbopuffer | Weaviate |
|---|---|---|
| Server philosophy | Build copilot: two tools — search the docs and execute TypeScript against the SDK in a sandbox — so the agent operates turbopuffer by writing and running code. | Built-in retrieval surface: discrete tools served by the database engine itself for schema inspection, tenant listing, hybrid query, and object upsert. |
| How the agent acts | Writes SDK code and runs it — list namespaces, write and query documents, inspect schema, and tune recall by exercising the real SDK rather than guessing at parameters. | Calls purpose-built tools directly — weaviate-query-hybrid, weaviate-collections-get-config, weaviate-tenants-list, and weaviate-objects-upsert. |
| Search model | Serverless vector and full-text search on object storage; the agent drives queries through SDK code it composes and executes. | Hybrid search that fuses vector similarity with keyword (BM25) matching in one query, so the agent recalls by meaning while honoring exact terms. |
| Deployment and auth | @turbopuffer/turbopuffer-mcp run locally over stdio via npx with a TURBOPUFFER_API_KEY (and optional region/namespace), or a hosted remote endpoint at turbopuffer.stlmcp.com with the key in a header. In beta, built on Stainless. | No separate package — enable MCP_SERVER_ENABLED and it serves at the /v1/mcp endpoint on the same port as the REST API, reusing Weaviate's existing API-key auth and RBAC. |
| Best-fit task | Integrating turbopuffer into an application and operating namespaces from the editor, with the agent learning the SDK by running it. | Adding agent-facing retrieval and memory to an existing Weaviate instance with hybrid search and a security model you already run. |
Verdict
Choose by how you want the agent to work and where your vectors live. Pick turbopuffer when you are building on it and want a copilot that grounds itself in the docs and operates the database by writing and running SDK code in a sandbox — ideal for integrating turbopuffer and tuning recall, with both local and hosted options (note it is in beta). Pick Weaviate when you already run a Weaviate instance and want a built-in, no-extra-install retrieval surface: enable the feature flag and the engine serves hybrid vector-plus-keyword search, schema inspection, and upserts, reusing your existing API keys and RBAC. turbopuffer is the SDK-driven build copilot; Weaviate is the engine-native retrieval surface. The decision follows your platform and whether you prefer code execution or discrete retrieval tools.
FAQ
- How does turbopuffer's server execute operations?
- It exposes a code-execution tool that writes TypeScript against the official turbopuffer SDK and runs it in an isolated sandbox, so the agent lists namespaces, writes and queries documents, and tunes recall by exercising the real SDK — plus a docs-search tool. Weaviate instead exposes discrete retrieval tools served by the engine.
- Does Weaviate's server need a separate install?
- No. As of Weaviate 1.37.1 the MCP server is built into the database engine: enable MCP_SERVER_ENABLED and it is served at /v1/mcp on the same port as the REST API, reusing Weaviate's existing API-key authentication and role-based access control.