Show HN: Antfly: Distributed, Multimodal Search and Memory and Graphs in Go (github.com)

107 points by kingcauchy ↗ HN
Hey HN, I’m excited to share Antfly: a distributed document database and search engine written in Go that combines full-text, vector, and graph search. Use it for distributed multimodal search and memory, or for local dev and small deployments.

I built this to give developers a single-binary deployment with native ML inference (via a built-in service called Termite), meaning you don't need external API calls for vector search unless you want to use them.

Some things that might interest this crowd:

Capabilities: Multimodal indexing (images, audio, video), MongoDB-style in-place updates, and streaming RAG.

Distributed Systems: Multi-Raft setup built on etcd's library, backed by Pebble (CockroachDB's storage engine). Metadata and data shards get their own Raft groups.

Single Binary: antfly swarm gives you a single-process deployment with everything running. Good for local dev and small deployments. Scale out by adding nodes when you need to.

Ecosystem: Ships with a Kubernetes operator and an MCP server for LLM tool use.

Native ML inference: Antfly ships with Termite. Think of it like a built-in Ollama for non-generative models too (embeddings, reranking, chunking, text generation). No external API calls needed, but also supports them (OpenAI, Ollama, Bedrock, Gemini, etc.)

License: I went with Elastic License v2, not an OSI-approved license. I know that's a topic with strong feelings here. The practical upshot: you can use it, modify it, self-host it, build products on top of it, you just can't offer Antfly itself as a managed service. Felt like the right tradeoff for sustainability while still making the source available.

Happy to answer questions about the architecture, the Raft implementation, or anything else. Feedback welcome!

26 comments

[ 5.2 ms ] story [ 52.6 ms ] thread
Interesting project.

I’ve got a project right now, separate vector DB, Elasticsearch, graph store, all for an agent system.

When you say Antfly combines all three, what does that actually look like at query time? Can I write one query that does semantic similarity + full-text + graph traversal together, or is it more like three separate indexes that happen to live in the same binary?

Does it ship with a CLI that's actually good? I’m pivoting away from MCP. Like can I pipe stuff in, run queries, manage indexes from the terminal without needing to write a client? That matters more to me than the MCP server honestly.

And re: Termite + single binary, is the idea that I can just run `antfly swarm`, throw docs and images at it, and have a working local RAG setup with no API keys? If so, that might save me a lot of docker-compose work.

Who's actually running this distributed vs. single-node? Curious what the typical user experience looks like.

This looks sick!

Did you build this for yourself?

in the query_test.go, I don’t see how the hybrid search is being exercised.

For fun I am making hybrid search too and would love to see how you merge the two list (semantic and keyword) and rerank the importance score.

Can you help me understand what type of practical features Graph Traversal unlocks?

I've seen it on a few products and it doesn't click with me how people are using it.

Was thinking to create something similar, well done!
(comment deleted)
As a longtime Raft user (via hashicorp/raft), I'm curious about your Raft implementation! You mention etcd's Raft library, but it isn't natively Multi-Raft is it? Is your implementation similar to https://tikv.org/deep-dive/scalability/multi-raft/ ? I'd love to hear about your experience implementing and testing it!
Of course the two most visionary people I worked with at Lytics went and built this. Just in time... this is the vector database I actually need. Termite is the killer feature for me, native ML inference in a single binary means I can stop duct-taping together embedding APIs for my projects. Excited to spend the upcoming weekends hacking on the Antfly ecosystem.
Curious why you decided to go with Go. Instead of Rust for instance.
Great question! I think the fundamentally hard problem with distributed systems (at least for me!) comes down to the complicated distributed state machines you have to manage rather than the memory management problems. I think async rust gets in my way with respect to these problems more than it helps (especially when it comes to raft or paxos). That being said with the new async Zig, I’ve been excitedly implementing a swappable backend for the core database that I hope will be a nice marriage of performance and ergonomics.
The idea is good, but the project isn't open. So I assume a rust fork will come out under MIT with these ideas, which can be the wider community adopted version.
https://github.com/antflydb/antfly/blob/main/src/store/db/in...

Comment on the Pause method indicates that waits for in flight Batch operations (by obtaining the lock) but Batch doesn’t appear to hold the lock during the batch operation. Am I missing something?

Nope! Awesome you’re poking around though. I’m currently working on deterministic simulation testing and a feature set to allow pausing of index backfills but it’s not fully implemented yet, stay tuned!
https://github.com/antflydb/antfly/pull/8

Upon another look it looks like we were actually missing the pause lock for the backfill operation too during a shard split though, I also went ahead and added it to batch for good measure although that case should be caught by the manager! Thank you for the report!

10:30 AM The Termite bundling is the most interesting part. Packaging embedding and reranking inference alongside the database means no separate model server to manage and no network hop for every vector op.

Curious about resource contention though: if a heavy indexing job saturates Termite, does that affect query latency on the Raft side? And how does Termite handle model cold starts in single-process mode?

On the license: the ELv2 framing is honest and the "can't offer as managed service" carve-out is pretty standard at this point. Won't bother most people reading this.

Thanks for the feedback!

In regards to contention, the answer is definitely dependent on how you host. We've had a lot of experience running different ML workloads and from an SRE perspective we knew you'd need a variety of different styles of hosting the models depending on read/write patterns of your usage. Termite and the proxy service/operator allow for all styles of model loading, either preloading and compiling to prevent cold starts or lazy loading to protect memory, with different pooling strategies and caching strategies for bundling multiple models running in the same Termite container.

If a heavy indexing job is running on a CPU only single-node deployment, it won't be using Raft (no replication). If it's running with GPU it doesn't share resources with the DB anyways really significantly there. If it's running distributed, also no issue with contention really.

Let us know if you have any other questions!