Market comparison
LS Search vs the incumbents
A straight spec sheet — including the rows where Pinecone, Weaviate, Qdrant, and Elasticsearch clearly lead. LS Search is the private, disposable, hard-isolated, low-cost option; it is not trying to win the enterprise-feature axes, and this table says so plainly.
| Capability | LS Search (量搜侠) | Pinecone | Weaviate | Qdrant | Elasticsearch |
|---|---|---|---|---|---|
| Privacy & isolation | |||||
| Data retention | None — disposed on session exit | Persistent until deleted | Persistent | Persistent | Persistent |
| Tenant isolation | Own gVisor sandbox pod per session/workspace | Namespaces (shared cluster) | Classes / multi-tenancy | Collections (shared cluster) | Indices (shared cluster) |
| Query logging | None, by design | Yes | Yes | Yes | Yes |
| Network egress from workload | Zero (blocked + flagged) | Managed cloud | Deployment-dependent | Deployment-dependent | Deployment-dependent |
| Data residency | EU + fully self-host | Multi-region (paid) | Region choice | Region choice | Region choice |
| Deletion & lifecycle | |||||
| Deletion guarantee | Structural + signed disposal receipt | API delete | API delete | API delete | API delete |
| Ephemeral / disposable | Yes — core design | No | No | No | No |
| Search & relevance | |||||
| Vector representation | Sign-bit binary (core), ~32× smaller | float32/int8 + PQ | float32 + PQ/BQ | float32/int8 + quantization | float32/int8 + BBQ |
| Hybrid keyword (BM25) + exact match | No — dense + rerank only | Yes (sparse-dense) | Yes (BM25 + dense) | Yes (sparse + dense) | Yes (native BM25 + kNN) |
| Reranking | Full-precision cosine rerank | Yes (rerank models) | Yes | Yes | Yes |
| Metadata / attribute filtering | No | Yes (rich) | Yes (rich) | Yes (rich payload) | Yes (rich) |
| Reverse-image / cross-modal built in | Yes — CLIP baked in | Bring your own embeddings | Modules (multi2vec/CLIP) | Bring your own embeddings | BYO / text via ELSER |
| Enterprise & ops (where the incumbents lead) | |||||
| High availability / DR / SLA | No — ephemeral by design | Yes (managed) | Yes | Yes (cloud) | Yes (mature) |
| RBAC / SSO / row-level ACLs | No — accountless by design | Yes | Yes (enterprise) | Yes (keys/JWT) | Yes (mature) |
| Query observability / eval | No — no query logs by design | Yes | Yes | Yes | Yes (mature) |
| Data-stack integration (CDC, connectors) | MCP server only | Connectors | Modules / connectors | Connectors | Broad (Beats/Logstash/CDC) |
| Compliance attestation | Not yet — verifiable architecture + self-host | SOC 2, HIPAA | SOC 2 | SOC 2 | SOC 2, HIPAA |
| Access & cost | |||||
| Deployment | Disposable sandbox + self-host | Managed SaaS only | SaaS + self-host (OSS) | SaaS + self-host (OSS) | Self-host + Elastic Cloud |
| Agent-native (x402 / MCP) | Yes — native, no account | No | No | No | No |
| Pricing model | Per-call x402, scale-to-zero, no account | Usage + plan minimum | Usage / subscription | Usage / subscription | Subscription / nodes |
| Energy per search | ~0.04 J est. (raw scan) | Not published | Not published | Not published | Not published |
Competitor capabilities reflect their standard offerings as of 2026-07 — these are strong, mature products, and this table is about fit, not a knock. Several enterprise rows (HA/DR, RBAC, query observability, deep integrations) trade directly against a no-logs, nothing-persists privacy model, so LS Search declines them on purpose. LS Search's own benchmarks are honestly measured: binary linear-scan loses to HNSW at recall parity — the wins are footprint, offload, and energy, not latency-at-scale.
Net: choose LS Search when privacy, ephemerality, hard isolation, and cost matter more than hybrid ranking, in-corpus RBAC, HA durability, and observability. For the opposite priorities, an incumbent is the right tool — and we'll say so.