Comparison

StrataFS vs. Elasticsearch — a detailed comparison

Q: Can I migrate from Elasticsearch to StrataFS?

If Elasticsearch is your source of truth, no — StrataFS reads from original files, not from an index. The migration story is: point StrataFS at the same files Elasticsearch was indexing, run them in parallel for a week, decide which results you prefer.

Q: Does Elasticsearch's vector search work as well as StrataFS's?

Elasticsearch supports dense_vector and HNSW since 8.0. Combined with text_expansion or RRF you get hybrid search. It works. Tuning weighted fusion with metadata signals takes more code than StrataFS's one SQL query, and you're paying cluster costs for it. For corpora that fit StrataFS's scale envelope, StrataFS is usually faster to set up and to run.

Q: Is StrataFS a replacement for the ELK stack?

No. StrataFS is a search engine, not an analytics platform. If you need Kibana dashboards, log aggregation, and time-series analytics, keep Elasticsearch. StrataFS replaces the 'we need a search service' part, not the 'we need analytics' part.

Elasticsearch is the cluster-scale workhorse of full-text and (since 8.0) vector search. StrataFS is the single-binary, MIT-licensed semantic filesystem optimised for per-developer and per-team deployments. The right tool depends on scale, ops appetite, and how close the index needs to be to the AI agent that consumes it.

Two tools, two scales

Elasticsearch is built for shared, large-scale, cluster-managed search. StrataFS is built for per-user, per-team, single-binary semantic search. The architectural choices come straight from those starting points.

Dimension	StrataFS	Elasticsearch
Runtime	Single Go binary	JVM cluster (1–N nodes)
Storage	SQLite + FTS5 + sqlite-vec	Apache Lucene + segment files
Cold start	~1 s	30–60 s
Warm hybrid query (10k chunks)	< 100 ms	< 100 ms
Warm hybrid query (10M chunks)	200–400 ms	100–200 ms
Multi-tenant	One DB per source	Native (indices/aliases)
Embedding generation	Built in (ONNX, local)	External or paid ELSER
MCP server for AI agents	Built in	Plugin / middleware
License	MIT	Elastic License v2 (source-available)

The hybrid-search story

Elasticsearch supports hybrid search well — bm25 plus knn plus RRF, or weighted fusion via script_score. It works. It also takes meaningful query engineering. StrataFS does hybrid in a single SQL statement with three configurable weights. The defaults work for code+docs corpora; tuning is one config change.

Practical consequence: a new “we need hybrid search” project takes hours in StrataFS and days–weeks in Elasticsearch. Extending an existing Elasticsearch deployment to add vectors is faster than adopting a new tool entirely.

The agent integration story

Elasticsearch was designed for human search. Wiring it to an AI agent as an MCP tool means writing a middleware that bridges JSON-RPC to ES query DSL, shapes results for the agent’s context window, and handles pagination/truncation. It’s a few hundred lines of code that you’ll then maintain.

StrataFS ships with a native MCP server. The tool catalog is four named entries. The response shapes are pre-trimmed for LLM context. Zero glue.

The operational story

Elasticsearch ops is a known discipline. You’ll deal with shards, replicas, JVM heap, GC pauses, snapshot lifecycle, ILM, and security plugins. The bench cost of running Elastic at non-trivial scale starts at one engineer’s part-time attention.

StrataFS ops is rsync. Backup is “copy the SQLite files”. Upgrades are npm i -g stratafs@latest. There is no cluster.

When the answer is “both”

Many teams end up running both: Elasticsearch as the shared service for cross-team and analytics workloads, StrataFS per-developer for codebase semantic search and agent retrieval. They don’t compete; they cover different points on the developer-experience spectrum.

For the longer narrative — including a decision tree — see our Elasticsearch vs. StrataFS article on the blog.

Pick StrataFS when

Per-developer or per-team deployment — single binary, zero ops
Corpus under ~50M chunks per logical scope
Hybrid FTS + vector + metadata in one SQL query, out of the box
Native MCP server for AI agents — no plugin, no middleware
Multi-storage indexing (Local + S3 + GCS + Azure + SharePoint + Drive + Jira)
Air-gapped or regulated environments — ONNX runs in-process, MIT license

Pick Elasticsearch when

Billion-scale corpora that need to be sharded across nodes
Centrally operated, multi-tenant search service for many internal customers
Kibana / analytics / aggregations alongside search (the whole ELK story)
Existing Elastic investment your platform team already runs well
Search SLAs measured in millions of queries per second

FAQ

Can I migrate from Elasticsearch to StrataFS?

If Elasticsearch is your source of truth, no — StrataFS reads from original files, not from an index. The migration story is: point StrataFS at the same files Elasticsearch was indexing, run them in parallel for a week, decide which results you prefer.

Does Elasticsearch's vector search work as well as StrataFS's?

Elasticsearch supports dense_vector and HNSW since 8.0. Combined with text_expansion or RRF you get hybrid search. It works. Tuning weighted fusion with metadata signals takes more code than StrataFS's one SQL query, and you're paying cluster costs for it. For corpora that fit StrataFS's scale envelope, StrataFS is usually faster to set up and to run.

Is StrataFS a replacement for the ELK stack?

No. StrataFS is a search engine, not an analytics platform. If you need Kibana dashboards, log aggregation, and time-series analytics, keep Elasticsearch. StrataFS replaces the 'we need a search service' part, not the 'we need analytics' part.