The build-vs-buy line for agent search lands at your Postgres footprint. If you run Postgres 13 or later, pgvector already provides exact and approximate nearest-neighbor search with vectors stored beside your relational data, which makes retrieval an incremental add rather than a new system. The managed alternative cannot currently be evaluated, for a blunter reason than immature docs: no Cloudflare page in the verifiable record shows a managed search product at all. The homepage pitches building for the agent era and the platform page sells agent-building blocks, but a retrieval primitive, its pricing, its availability status, and its access-control documentation appear nowhere in any source this article could verify.
What is actually verifiable?
Almost nothing, and that is the finding. There is no product page, no pricing, no GA-versus-waitlist status, and no access-control or governance detail for any Cloudflare managed search offering, because no fetched Cloudflare page names one.
What the pages do show is positioning. Cloudflare’s homepage is titled ‘Build for the agent era’, and the connectivity-cloud page markets an agents framework, orchestration tools, and the ability to ‘build, deploy, and secure access for remote MCP servers so agents can access the features of your apps’. That is a vendor assembling the layers around an agent stack and, on the current record, stopping short of a retrieval primitive.
The shelf around the empty slot is stocked. Wikipedia’s Cloudflare article records edge computing through the Workers platform, the 1.1.1.1 resolver, WARP, and, in recent years, AI integrated into its infrastructure by ‘acquiring companies such as Replicate and launching tools to manage AI bots and scrapers’. Whether a managed retrieval layer is the next entry on that list is exactly the kind of question primary documentation exists to answer, and none is fetchable yet.
What does a Postgres 13+ team already have?
A team on Postgres 13 or later already has production-grade vector search available as an extension install, not a platform project.
Per the pgvector repository, the extension is open source, supports Postgres 13 and later, and provides both exact and approximate nearest-neighbor search, storing ‘vectors with the rest of your data’. The documented surface is broad: single-, half-, and binary-precision vectors plus sparse vectors, six distance functions including L2, inner product, and cosine, and quantization for when the vector count grows. The approximate path is tunable by the operator rather than by a vendor’s defaults. Those distance functions are SQL operators rather than API parameters: <-> for L2, <#> for inner product, <=> for cosine, <+> for L1, plus Hamming and Jaccard for binary and sparse types. A nearest-neighbor query is SELECT * FROM items ORDER BY embedding <-> '[3,1,2]' LIMIT 5; the statement that fetches context for an agent is the same kind of query your application already runs, planned and EXPLAINed like every other statement you ship. The retrieval substrate that a managed primitive would sell you already exists in a database you run.
The decisive property is colocation, and it pays off in the least glamorous way possible. Embeddings live in tables beside the source documents and the permission rows that govern them. Access control becomes a JOIN and a WHERE clause inside the query plan, not an integration layer bolted between a vector service and an identity system. Backup, replication, and point-in-time recovery are whatever your Postgres runbook already says, because the index is inside the thing you already operate. Freshness follows the same logic: a row and its embedding can be written in the same transaction, so index staleness equals your embedding-pipeline lag, measured by your own monitoring rather than translated through a vendor SLA.
The honest limits matter too. pgvector is not a reranker and not an embedding model. If the bar is a multi-stage pipeline (retrieve, rerank, generate), you assemble those stages yourself, the same assembly the self-hosted pgvector-or-Qdrant-plus-reranker framing implies. A managed search primitive would have to win on operational burden, because on documented capability the self-hosted baseline already covers the retrieval layer.
Where does the build-vs-buy line land?
The line falls where your existing footprint is: teams already on Postgres 13+ should build now and hold the buy decision until primary documentation exists, while teams without a database in play face a different and harder choice.
Do you already run Postgres?
If yes, vector search is an extension and a schema change. The operational surface grows by an index type inside a system you already staff and monitor. If no, the calculus changes shape: adopting Postgres to obtain pgvector is a platform decision, not a feature decision, and standing up a dedicated vector database such as Qdrant alongside your existing stores may be the more honest self-hosted path. The comparison in this article is sharpest for the first group, because for them the incremental cost of building rounds to nearly zero.
What retrieval capability do you need?
The self-hosted baseline is documented: exact search for small corpora or auditability-critical workloads, approximate search as corpora grow. The managed baseline is undocumented. In modern retrieval stacks the differentiator is rarely the index anyway; it is the rerank stage and the evaluation harness behind it. Neither comes from pgvector, and neither appears anywhere in Cloudflare’s verifiable product surface. On capability, then, one side of the comparison is published and the other does not exist in the record.
How much vendor concentration can you stomach?
Cloudflare’s platform page markets over 60 cloud services on one unified platform (vendor-reported). Consolidation is the product: one contract, one auth model, one observability surface. The cost is correlated exposure. When a consolidated vendor reprices or retires a service, everything downstream of that service reprices with it, and a search primitive that agents call on every query sits deep in the dependency graph. Search is the last component you want to be the first one you have to migrate.
How stable is the vendor?
Wikipedia’s Cloudflare article reports FY2025 revenue of $2.168 billion3 against an operating loss of $207 million3 and a net loss of $102 million3, with 5,156 employees3, and it records significant global outages in late 2025 that disrupted services for major platforms internationally. A vendor that spends more than it earns while assembling an agent stack is not a disqualifier; the growth-infra playbook runs on exactly that. The operational record is the part a buyer inherits: outages that disrupt major platforms internationally are what a retrieval primitive sits on top of, and support thins at the periphery first. A product with no verifiable public footprint has no way to prove which side of that record it would sit on.
Who governs the corpora?
Agent search over company data means the corpus becomes queryable from outside your perimeter, or leaves it outright. That is the governance question a managed primitive forces, and for self-hosted retrieval the answer is trivial: the corpus never moves. On the buy side, the corpus crosses into a vendor whose connectivity-cloud page pitches connecting ‘workforce, AI agents, apps, and infrastructure’, and the terms of that crossing, processing regions, retention, subprocessors, become contract items rather than runbook entries.
Document-level access control is the make-or-break feature for internal corpora. Retrieval that cannot filter by permission at query time is unusable behind a corporate perimeter, and post-filtering approximate results silently degrades recall for restricted users, who see a thinner index than everyone else. pgvector answers this structurally, with the ACL table in the same database as the vectors. Whether any managed primitive answers it at all is unpublished.
Can you trust Cloudflare’s platform numbers?
As descriptions of network reach, plausibly; as evidence about a search product, not at all.
The numbers in circulation are homepage claims: 335+ cities1 within 50ms of 95% of the world’s population1 and 42% of the Fortune 5001 as customers per the Cloudflare homepage, and 234 billion cyber threats2 blocked daily, 20% of all websites protected2, and 500 Tbps2 of DDoS-absorbing capacity per the connectivity-cloud page. All of it is vendor-reported; none of it is an audited benchmark. Network-reach counts do not decide a relevance decision either way.
More to the point, none of these figures bears on retrieval. Threat-blocking volume and network capacity describe a CDN and security posture, and 42% of the Fortune 5001 using some Cloudflare service is a logo wall, not a reference customer for a retrieval API. The numbers that would matter to a buyer, cost per query, freshness guarantees, filtered-query recall, appear on no fetched page, because no fetched page describes the product.
What do the acquisitions signal?
Cloudflare’s direction is legible from what is on the record. The connectivity-cloud page markets an agents framework and orchestration tools; Wikipedia’s Cloudflare article records the company ‘acquiring companies such as Replicate’ alongside ‘launching tools to manage AI bots and scrapers’; and the homepage’s title stakes the company on the agent era. Retrieval is the layer this inventory does not yet list.
When retrieval, embeddings, and the query interface become one managed primitive, RAG stops being something a platform team assembles from components and becomes something it procures. The evaluation vocabulary shifts accordingly, from technical choices (which embedder, which index type, which reranker) to commercial ones (which plan, which quota, which region, which retention policy). That shift is not inherently bad; procurement is often cheaper than assembly. But it prices in a migration that gets more expensive the longer you wait, because embeddings are model-specific. Switching retrieval vendors usually means re-embedding the entire corpus and re-tuning retrieval quality from scratch. Lock-in in search is stickier than lock-in in a CDN, since the index is derived from your data while the embedding function that produced it is not portable.
When should you build, and what must be verified before you buy?
Build now on pgvector if you run Postgres 13+, and hold the buy decision until primary documentation answers five specific questions.
The build path is short and reversible: install the extension on your existing instance, use exact search for small corpora and the approximate path as the corpus grows, keep embeddings in the same database as the permissions that govern them, and let your own pipeline define freshness. Every one of those properties is documented in the pgvector repository, which is more documentation than any would-be managed competitor currently has on the record.
Reversibility is the property the buy side cannot match. The artifacts of the build path are ordinary Postgres objects: tables, a vector column, an index, a scheduled job that refreshes embeddings. Walking away from them is a dropped column and a DROP EXTENSION, not a corpus export through an API whose terms you negotiated at procurement time.
The limitation that governs this whole article deserves its own plain statement: the buy side does not appear in the verifiable record. No Cloudflare page fetched for this article names a managed search primitive; pricing, availability, freshness, access control, and governance are absent from every verifiable primary source, and the Wikipedia-derived context that survives here is only what the cached article supports. The decision framework above survives those gaps. The product assessment does not exist yet, and any article that renders one is reviewing intent.
A homepage that says ‘Build for the agent era’ announces intent. The build-vs-buy line does not move until the documentation does.
Frequently Asked Questions
How does pgvector’s HNSW index performance compare to dedicated vector databases like Qdrant for large corpora?
pgvector’s HNSW implementation is generally slower than Qdrant’s optimized Rust-based engine for datasets exceeding 10 million vectors, often requiring 2-3x more RAM to maintain similar recall. However, pgvector avoids the network latency of a separate service, which can offset the CPU cost for low-latency, high-concurrency internal tools where the database is already co-located with the application.
What is the operational cost of migrating from pgvector to a managed service if the vendor changes their embedding model?
Migration typically requires re-embedding the entire corpus, which can cost $0.01 to $0.05 per 1,000 tokens depending on the model, plus the compute time to run the batch job. For a 10-million-document corpus, this can result in a one-time cost of $5,000 to $25,000 and several days of pipeline downtime, making the ‘exit path’ a significant financial and operational risk that must be priced into the initial procurement decision.
Does pgvector support multi-tenant isolation without application-level filtering?
No, pgvector does not have built-in row-level security (RLS) integration for vector search that automatically filters by tenant ID at the index level. You must implement tenant filtering via SQL WHERE clauses, which means the approximate nearest neighbor search may retrieve candidates from other tenants before filtering, potentially degrading recall if the index is not partitioned by tenant. This requires careful schema design, such as partitioning tables by tenant, to ensure performance and isolation.
How does Cloudflare’s May 2026 workforce reduction impact the long-term stability of its agent infrastructure?
The elimination of ~1,100 roles (20% of workforce) suggests a strategic pivot toward higher-margin, consolidated services, which may deprioritize niche or experimental features like early-stage retrieval primitives. Teams relying on Cloudflare for agent search should monitor the company’s quarterly earnings calls for mentions of ‘agent infrastructure’ revenue, as a lack of specific metrics could indicate the feature is being absorbed into broader platform offerings rather than developed as a standalone product.
