Two years ago this was a forced buy — your CRM had no semantic search, so you bolted on Pinecone or Weaviate. In 2026 every major CRM ships native vector storage and hybrid search. The question stopped being “do I need a vector DB” and started being “is the native one good enough for my workload, or am I paying for vendor lock-in I don’t need.”
How we got here
Through 2023–2024, every CRM AI project started with “pick a vector DB.” Pinecone collected logos. Weaviate, Qdrant, Chroma, Milvus all built CRM integration stories. The pattern was: CDC out of the CRM, embed, index in the vector DB, query from the agent.
The pattern leaked. Sharing rules broke. Embedding drift compounded. The CDC pipeline was always one schema change away from failure. Customers complained about latency on every cross-cloud round trip.
CRM vendors responded by building native vector storage. By mid-2025 every major vendor shipped it. The economics flipped — for CRM-resident data, native became the default, and bring-your-own became the exception you justify with specific requirements.
The native options in 2026
- Salesforce Data Cloud — vector search GA since Spring ‘25. Hybrid (BM25 + vector). Indexes Data Cloud objects natively, no ETL. Tight integration with Agentforce grounding.
- Microsoft Dataverse — Azure AI Search-backed semantic index. Hybrid + semantic ranker. Native Copilot Studio grounding.
- HubSpot Smart CRM — Breeze Intelligence semantic search, GA mid-2025. Embeddings over contacts, companies, deals, tickets, notes, and KB.
- ServiceNow — Now Assist Knowledge Graph plus dedicated vector store for embeddings. AI Search hybrid mode.
- Zoho — Zia Search with semantic ranking, smaller scale but functional for SMB.
These are not toys anymore. They’re production-grade for the data already in the CRM.
Two architectures, same picture
The native architecture:
[Agent runtime] --tool call--> [Native vector + record API in one]
|
CRM records
(embeddings auto-maintained)The BYO architecture:
[CRM] --CDC--> [ETL] --embed--> [Vector DB]
^
|
[Agent runtime] --tool call------------+Native has one box. BYO has four, plus the arrows. Each arrow is an opportunity for drift, lag, security misconfiguration, or cost surprise. That’s the operational reality you’re signing up for when you go BYO.
Where native shines
- Zero-ETL grounding. Vectors live with the records. No CDC pipeline, no embedding drift, no orphaned indexes when a deal is deleted.
- Sharing-aware retrieval. Native search respects record-level security automatically. Salesforce Data Cloud’s vector index honors sharing rules at query time. Pinecone doesn’t know what a sharing rule is — you build that yourself.
- Identity integration. Queries run as the user, not as a service account. Audit trail intact.
- Lower operational burden. No separate cluster to size, scale, patch, monitor, back up.
- Tighter latency to the agent runtime. Co-located with Agentforce / Copilot Studio / Breeze. Saves 30–80ms round trip.
Where native struggles
- Cross-system data. Native vector stores index native records. If your knowledge lives in Confluence, Notion, Google Drive, Sharepoint, plus the CRM, you’re either replicating into the CRM (expensive) or running a second index anyway.
- Custom embedding models. Most native stores lock you into the vendor’s embedding model. If you need a domain-finetuned embedder (legal, medical, multilingual), bring-your-own is limited.
- Index tuning. HNSW parameters, quantization, sharding strategy — native stores don’t expose them. You get what they tuned for the median customer.
- Cost at high scale. Native pricing is usually per-record or per-query. At 100M+ vectors it gets ugly compared to Pinecone serverless or Qdrant self-hosted.
- Vendor lock-in. Your embeddings are now a Salesforce / Microsoft asset.
A short hit list of failure modes by choice
Native pitfalls:
- Index update delay during heavy bulk loads (re-embedding 10M records can run hours).
- Quota limits on query volume — agentic loops at 5+ retrievals per question hit them fast.
- Limited embedder choice locks you into the vendor’s quality ceiling.
BYO pitfalls:
- CDC pipeline failures silently corrupt the index (deletes don’t propagate, updates lag).
- Sharing-rule replication drift exposes data to wrong users.
- Cost spikes from QPS bursts on consumption-priced vector DBs.
- Re-embedding migrations during a model upgrade with no transactional story.
Pick your poison knowingly.
Decision matrix
# vector_decision.yaml
inputs:
data_locations:
- crm_records: true
- external_kb: true | false
- product_telemetry: true | false
- unstructured_files: true | false
scale:
vector_count: 1e6 | 1e7 | 1e8 | 1e9
queries_per_second: 10 | 100 | 1000
requirements:
sharing_aware: true | false
custom_embedder: true | false
sub_100ms_p95: true | false
constraints:
avoid_vendor_lockin: true | false
ops_team_size: small | medium | large
decision_rules:
- if data_locations == crm_only and scale.vector_count < 1e7:
pick: native_crm_vector
- if sharing_aware and crm_records and not external_kb:
pick: native_crm_vector
- if external_kb or unstructured_files or custom_embedder:
pick: byo_vector_db
- if vector_count > 1e8:
pick: byo_vector_db # cost
- if avoid_vendor_lockin and ops_team_size >= medium:
pick: byo_vector_db
- default: hybridLatency benchmarks observed in production
Round-trip retrieval latency at p95, from agent runtime, single-tenant, warm cache:
| Setup | p95 |
|---|---|
| Data Cloud vector (native, in same Salesforce org) | 110ms |
| Dataverse + Azure AI Search (same region) | 140ms |
| HubSpot Breeze native | 160ms |
| Pinecone serverless (cross-region) | 220ms |
| Qdrant Cloud (cross-region) | 180ms |
| Self-hosted Qdrant in same VPC as agent | 60ms |
| pgvector co-located | 45ms |
Co-located self-hosted wins on latency. Cross-cloud BYO loses 100–150ms to network and TLS. For sub-second total-response budgets, the location of the vector store matters more than the algorithm.
The hybrid pattern (most common 2026 setup)
In practice, large customers run both:
- Native vector for CRM records and sharing-aware retrieval.
- External vector (Pinecone, Qdrant, Weaviate, or pgvector) for the rest — docs, emails, transcripts, third-party data.
- A router in front decides which store to hit per sub-question.
The router is small. The cost is operational complexity. The win is you stop paying CRM-vendor markup on every embedding while keeping security-aware retrieval where it matters.
Cost: the real math
A 50M vector workload, 1024-dim embeddings, ~200 QPS.
| Option | Year 1 list | Year 1 effective |
|---|---|---|
| Salesforce Data Cloud vector (native) | included in DC SKU + per-record | ~$280k |
| Dataverse + Azure AI Search | bundled-ish | ~$220k |
| HubSpot Breeze Intelligence | tiered | ~$180k |
| Pinecone serverless | usage-based | ~$95k |
| Qdrant Cloud | usage-based | ~$70k |
| Self-hosted Qdrant on EKS | infra + ops | ~$45k + 0.5 FTE |
| pgvector on existing Postgres | infra only | ~$15k + 0.25 FTE |
Native looks expensive in isolation. Add the cost of replicating CRM data into the external store (CDC pipeline, schema drift handling, security replication) and the gap narrows fast. For sub-10M vectors, native usually wins on total cost of ownership.
The lock-in question
Embeddings are sticky. Re-embedding 100M vectors with a different model costs real money — not just compute, but evaluation drift. Whichever embedder you pick, you’ll be living with it for 18+ months.
Native vendors know this. The lock-in is real. Mitigations:
- Store source content alongside vectors so re-embedding is mechanical, not archaeological.
- Pick a vendor that supports BYO embedder if you’re large enough to negotiate.
- Use a stable open-source embedder (BGE, E5, GTE families) so you can re-embed on your own infra later.
Embedding dimension and quantization
Most native stores fix the embedding dimension (often 1024 or 1536). BYO lets you pick. This matters when:
- You want smaller embeddings (384-d for cost / speed).
- You want larger embeddings for higher recall.
- You want binary or scalar quantization to cut memory 4–32x.
Quantization changes the cost equation. A 100M vector index at 1536-d full precision is ~600GB. At binary quantization with reranking, it’s ~20GB. The latter fits in memory; the former runs from disk. 10x speedup, 2-3% recall loss, big cost delta. BYO supports this; native usually doesn’t expose the knob.
Sharing-aware retrieval is the hidden moat
Most teams underestimate this. If your CRM has record-level security (it does), and your retrieval doesn’t respect it, your agent will surface data the user shouldn’t see. This is a real compliance issue, not a theoretical one.
Native vector stores enforce sharing at query time. Bringing-your-own means you must either:
- Replicate the sharing model into your external store (fragile, complex, perpetually out of sync), or
- Post-filter results against the CRM at query time (latency hit, partial results), or
- Restrict the index to non-sensitive data only (defeats half the purpose).
For regulated industries — financial services, healthcare under HIPAA, public sector — option 0 is “use the native store and stop fighting it.”
Migration paths
If you started on Pinecone and want to consolidate:
- Inventory which retrievals actually need cross-system data. Most don’t.
- Move CRM-record retrievals to native first. Measure quality delta.
- Keep external store for cross-system / unstructured / custom-embedder cases.
- Re-route the router. Decommission the unused half of Pinecone.
Reverse migration (native → BYO) is harder. Once you’ve embedded inside Data Cloud or Dataverse, getting the vectors out is API-rate-limited, sometimes contractually restricted, and re-embedding may be required.
Hybrid search: don’t skip it
Pure vector search underperforms hybrid (BM25 + vector + reranker) on most CRM workloads. CRM data has named entities — account names, product SKUs, opportunity stages — where lexical match matters. Pure vector loses these. All native stores now ship hybrid by default. Most BYO stacks have to wire it up.
If you’re benchmarking native vs BYO, benchmark hybrid vs hybrid, not vector vs vector. Otherwise you’re comparing apples to oranges and the native option will look unfairly bad.
Operational considerations few teams plan for
- Backfill cost. Re-embedding 50M records during a model upgrade costs ~$5k–$50k depending on embedder. Plan for at least one re-embed per year.
- Index drift. Records change. If your CRM updates an account description, does the vector index update? Native: yes, immediately. BYO: only if your CDC pipeline catches it. Stale embeddings are a silent quality drag.
- Deletion propagation. GDPR right-to-deletion means a contact is purged. The vector must go too. Native handles this. BYO: you need to implement deletion CDC.
- Multi-tenant isolation. If you’re a CRM-adjacent SaaS, your customers’ tenants must not bleed into each other in retrieval. Native enforces via sharing. BYO: per-tenant namespace + query-time filter.
- Embedding model upgrade. When BGE-v4 ships and you want it, can you switch? Native: vendor’s call. BYO: yours, with backfill cost.
When the answer is “neither, use SQL”
Worth saying. Many CRM “AI search” needs are not semantic. “Show me opportunities over $100k closing this quarter in West region” is a SQL query, not a vector query. Don’t embed your way out of a structured-data problem.
The agentic pattern: triage the query. Structured → SQL. Semantic / fuzzy → vector. Hybrid → both, joined.
Bottom line
- For CRM-record-only workloads under 10M vectors, native is the right default in 2026.
- The moment your data spans CRM + docs + telemetry, you need a router and probably both.
- Sharing-aware retrieval is the killer feature most BYO setups silently break.
- BYO wins at high scale (>100M vectors) and when you need a custom embedder.
- Whatever you pick, store source content separately — embeddings are sticky and re-embedding will happen.
