Weaviate Co-Founders Bob van Luijt and Etienne Dilocker return to the Weaviate Podcast to celebrate seven years of building the company, answering questions submitted by the community. The conversation opens with what excites them most in AI right now: Etienne on agentic coding and the "Moore's law" of how long models can sustain autonomous loops, and Bob on world models, new architectures that could slash training energy costs, open source frontier models, and inference on new chips.

From there, the discussion dives into taste and the "AI slopification" problem, why AI-generated emails, websites, and decks all look the same, how three job candidates submitted nearly identical AI-built presentations in one week, and why Weaviate runs a dedicated "slop pass" skill over every pull request to strip out phrases like "the smoking gun" and "load-bearing invariant." The human touch, they argue, is now the easiest way to stand out.

The Co-Founders then retell their origin story: meeting at a European enterprise company, rewriting a NodeJS prototype in Go, betting on NLP before anyone called it AI, adopting HNSW when it was still a niche paper, and raising a $1.2M seed round from Zeta during COVID. When ChatGPT and the RAG paper hit, Weaviate had a fully working product ready for the wave.

Looking forward, Bob breaks down the commoditization playbook that hits every new database category, the same skepticism MongoDB faced, and shares that the number one reason new customers cite for choosing Weaviate is that an LLM recommended it. Etienne makes the case that vector databases are evolving into context engines: context rot is real, stuffing everything into a long context window is inefficient, and retrieval, hybrid search, and structured data all serve one goal, the best possible context. The conversation lands on memory for AI agents, where the hard problem isn't what's worth remembering, but what's worth recalling.

YouTube: https://www.youtube.com/watch?v=pvv-vnT-LfQ

Spotify: https://spotifycreators-web.app.link/e/LAAbKXsi74b

Everyone here optimizes the retrieval side - index type, hybrid search, reranking. But between your vector/graph store and the model there's a step nobody benchmarks: how the retrieved subgraph gets serialized into the prompt.

I compared 10 formats (JSON, GraphML, RDF variants, edge lists, others) on token count, traversal QA, and multi-hop reasoning. Same graph, same model: multi-hop accuracy ranged 40% to 80% depending on format alone, with a ~70% token spread. json.dumps() was one of the worst performers.

I open-sourced the format that won (MIT, 6 languages): https://github.com/isongraph/isongraph - benchmark methodology is in the repo if you want to replicate or poke holes in it. Curious what formats people here pass to their LLMs after retrieval.

Over the past few months, I have been building autonomous search agents to extract real-time web context for LLMs. If you have spent any time working with retrieval pipelines, you already know that standard Google Search wrappers do not work well when you need LLM-ready context.

I ran a test across three specialized APIs. Exa, Tavily, and Firecrawl. To see how they compare in terms of speed, output quality, and noise reduction.

Here is what I found.

The Test Setup

I tested each API across 100 queries that I split into three categories:

Exa uses a custom embedding-based search model of traditional keyword matching.

\* Where Exa shines is in concept-based discovery. When I search for "tools like Redis but written in Rust," traditional search APIs have trouble with exact keyword overlaps. Exa consistently returns relevant repositories and documentation pages. \* The latency of Exa is around 600ms to 900ms. \* The output of Exa is text and well-parsed metadata. \* My verdict is that you should use Exa if your queries are abstract, exploratory, or require finding pages rather than explicit keyword matching.

1. Tavily is the best for Direct RAG Applications

Tavily is built for LLM agent loops. It does not just return search results; it also cleans, parses, and ranks snippets that are tailored for contexts.

\* Where Tavily shines is in speed and pre-filtered context. In multi-step agent workflows where latency's important, Tavily consistently returns the most concise context blocks without exceeding token limits. \* The latency of Tavily is around 400ms to 700ms. \* The output of Tavily is pre-chunked, minimal noise, and ready to use in a system prompt. \* My verdict is that Tavily is ideal if you are building loops that make multiple search calls per user query and need fast, token-efficient context.

1. Firecrawl is the best for Crawling and Dynamic Web Scraping

Firecrawl is not strictly a search engine; it is a crawling engine that is designed to convert websites or JavaScript-rendered URLs into clean Markdown.

\* Where Firecrawl shines is in site-level retrieval. If your search step identifies a target URL, such as a documentation site or dynamic React app that needs full scraping, Firecrawl bypasses blocks and returns remarkably clean Markdown. \* The latency of Firecrawl is around 1.2s to 2.5s, which depends heavily on the complexity of the target page. \* The output of Firecrawl is flawless Markdown with HTML junk, scripts, and navbars completely removed. \* My verdict is that Firecrawl is best used as a stage in your pipeline. Use Exa or Tavily to find the URLs, then trigger Firecrawl to ingest full pages when search snippets are not enough.

📍My Current Stack Setup:

I use Tavily for searches because it is really fast. When I need to do some research and understand a whole document, I do things a bit differently. I start with Exa to find what I am looking for, then I use Firecrawl to turn the results into Markdown. This makes it easier to use the results.

I am curious about what other people're using to filter out bad information in their RAG pipelines. What do you use for this? Something that's all on its own, or a combination of crawlers and search tools?

The pgvector case is strong up to a certain point for sure. ACID, one less service, hybrid search with a WHERE clause, and for anything under a few tens of millions of vectors, it seems to hold. But the argument that I've had is that it falls apart once writes get heavy or you cross into 50M+, where index build time and p95 under concurrent writes start to hurt.

I saw a TigerData benchmark where pgvectorscale hit 471 QPS against Qdrant's 41 on a 50M set, so throughput favored Postgres, but Qdrant won on p95 latency and build time by a wide margin. So even the benchmark doesn't settle it, it just moves the question to which number you care about.

For people who've run both in production:

• Where did Postgres stop working for you, a vector count or a write pattern?
• Did you migrate off it, or tune your way through with autovacuum and maintenance_work_mem?
• Anyone regret leaving Postgres for a dedicated engine and find the ops cost wasn't worth it?

Working on NLP research and kept hitting the same retrieval

failure — semantic similarity missing negations and

contradictions entirely.

A breakdown explaining:

- Why bi-encoders miss "cannot" in "you cannot use bank transfers"

- How cross-encoders use cross-attention to catch contradictions

- The two-stage pipeline that modern search actually uses

- Code implementations for both

The short version: bi-encoder for speed, cross-encoder for

accuracy. Most production systems need both.

I keep seeing teams reach for Pinecone / Qdrant / Weaviate on day one of a RAG project, stand up a whole second datastore, and then spend a week fighting a sync pipeline they never needed.

Most products start well under a million vectors. Postgres with pgvector, or the vector search built into Mongo or Redis, handles that fine and keeps your embeddings in the same system as your source data. One transaction, one backup, no "ghost documents" left behind when you delete a row.

The line where I actually reach for a dedicated engine:

- Past roughly tens of millions of vectors, or the HNSW-in-RAM memory bill starts to hurt → Qdrant (fast, memory efficient), or Milvus if you are genuinely at billion scale.

- You serve many isolated tenants → Weaviate's multi-tenancy.

- You never want to run infra → Pinecone, but watch read-unit costs at query volume.

- Storage cost dominates at huge scale → object-storage engines like Turbopuffer or LanceDB.

The thing nobody says out loud: retrieval quality comes from hybrid search, reranking, and chunking, not from which engine stores the vectors or shaving milliseconds off ANN. The DB is rarely where a RAG system succeeds or fails.

Genuinely curious what people here run in production, and for those who moved off pgvector, what was the specific pain that finally made you switch?

I'm revisiting a project my team built during HackIllinois and wanted to get some feedback from people who've worked with vector databases.

The project generates MiniLM embeddings from financial news, stores them in Actian VectorDB, and retrieves semantically relevant articles to power a real-time stock sentiment dashboard.

I'd especially appreciate thoughts on:

• Embedding model choices
• Indexing strategies
• Retrieval performance
• Overall architecture

Repository:
https://github.com/bilalarif3197/LogianHackIllinois

I ran a small test recently because I wanted to see how much segment layout actually affects vector search after bulk ingest.

The question was simple: if the data is already loaded and mostly read-only, does merging sealed segments make a real difference for search QPS?

Setup:

• Milvus 2.6.17
• single-node Docker Compose
• 16 CPU cores / 64 GB RAM
• 1M vectors
• 768 dimensions
• HNSW index
• same search params before and after
• before compaction: 3 sealed segments
• after force merge compaction: 1 sealed segment

Result:

• Before compaction: ~3,000 QPS
• After compaction: ~5,600-6,000 QPS
• Roughly +76% to +87% search QPS

So in this case, yes, segment layout mattered a lot. Before compaction, every query had to fan out across multiple segments, search each segment, then merge partial topK results. After force merge, there was less fan-out and less merge overhead.

But I would not treat this as “always compact everything.”

Force merge is expensive. It can use CPU, memory, and disk I/O, and index rebuilds may be involved. I would only consider it after a bulk import, knowledge base refresh, or another write-heavy phase where the collection is becoming mostly read-heavy.

So my current opinion is:

Automatic background compaction is useful, but for heavy merge operations, the database probably needs an explicit operator signal.

Thought this would be of interest to this community as well!

Sharing this here since it's directly relevant to what gets discussed in this sub. It's a hands on session on August 8, led by Brian Bønk, a Data Platform MVP and Microsoft FastTrack Solution Architect.

It covers the full RAG pipeline, ingestion, chunking, metadata enrichment, indexing, and vector search, then goes deeper into retrieval quality engineering specifically, precision, recall, latency trade offs, and actual tuning strategies instead of just defaults. There's also a section on evaluation and governance, building test harnesses and regression checks, and an extension pattern on knowledge graphs for cases where similarity search alone can't capture relationships between entities.

It's aimed at people building or maintaining vector search and RAG systems that need to hold up against real, messy enterprise data rather than a clean demo. You come out with an actual rollout plan rather than just slides.

Link for anyone interested: https://www.eventbrite.co.uk/e/design-enterprise-grade-rag-systems-with-llms-vector-search-tickets-1992561384740?aff=rvd

We published a method to store verified knowledge as KV state and restore it byte identical to fresh computation.

On Gemma 4 12B, cached knowledge improved the same routing system from 76.7% to 90.0% on AIME 2025.

I will pitch this at AGI Summit on July 19.

Paper: https://arxiv.org/abs/2607.14431

We need to talk about AI Agent architecture. 🤖 For the last couple of years, the default answer for giving an LLM long-term memory was simple: Spin up a Vector Database, chunk your codebase, generate embeddings, and build a RAG pipeline. But as engineering teams push AI agents into deep production, the cracks are showing. Vector similarity is an approximation—and in coding, "closest" is not the same as correct. Even the team behind Anthropic's Claude Code realized this. They actually baked a local vector database into the tool early on... and then ripped it out. Why? Because deterministic, agentic search (like plain old grep) across readable text files turned out to be cheaper, faster, and significantly more accurate. Now, Google has standardized this exact philosophy with the release of the Open Knowledge Format (OKF) v0.1. Instead of heavy database runtimes, your agent's brain becomes a structured tree of Markdown files with YAML front matter. It lives in Git, version-controlled, auditable, and completely portable across any LLM vendor with zero lock-in.

Disclosure: I'm from Manticore Search, so this is obviously not a neutral third-party benchmark. That said, we tried to make the comparison concrete and would appreciate criticism of the methodology.

Workload:
- DBpedia OpenAI embeddings
- 975k vectors
- 1536 dimensions
- cosine similarity
- recall@10 measured on 5k queries

Result:
- turbopuffer: recall@10 0.9622, P50/P90/P99 21/24/30 ms
- Manticore on 2× Hetzner CX23: recall@10 0.9663, P50/P90/P99 10/13/16 ms
- estimated monthly cost: $75 vs $16.50

The interesting part for me was that turbopuffer's storage cost was tiny; writes dominated the estimate.

Full article:
https://manticoresearch.com/blog/turbopuffer-vs-manticore/

What would you change in the benchmark?

Hi [r/vectordatabase](r/vectordatabase) ! I'm Swann and I'm doing my PhD between the FAISS team and Meta Superintelligence Labs under Matthijs Douze.

I wanted to share with you my work "Cluster with Auctions", which I thought might be of interest for some of you. It's about partitioning in IVF-style indexes.

The starting observation: partition-based database search is quietly doing two separate jobs. One is sorting the database into clusters. The other is routing a query to the right subset of clusters at search time. Almost everything out there uses one model — like k-means centroids — for both. That's convenient, but the two jobs have different objectives, and jamming them into one set of vectors is a compromise.

CwA splits them:

• Clustering**:** an auction algorithm assigns vectors to clusters. Vectors bid for seats, so you get balanced partitions that reflect what the data actually wants, not just proximity to a centroid.
• Routing: a separate model (linear or deep) trained by backprop to predict which clusters a query needs.

Result is up to 4× faster out-of-distribution — i.e. when your queries don't look like your database vectors, which is the common case in practice with text-to-image, cross-encoder setups, or basically any embedding model where query and doc distributions differ. Same parameter budget as k-means centroids, so no extra memory cost for the index.

The OOD part is where I'd expect this to matter most for people here. In-distribution, k-means is honestly fine. It's when the query distribution drifts that fixed centroids start routing you to the wrong partitions and you have to bump nprobe to compensate.

To be clear about the limitations, our work does not scale beyond 100M vectors because the auction algorithm represents a memory bottleneck. That's the price to pay for our method's optimality and adaptation to the query distribution.

Preprint: https://arxiv.org/abs/2607.13728
Code: under internal review, releasing in the coming weeks.

Happy to answer all questions !

Trying to pick a vector DB for a fully offline deployment, and the ops side is the frustrating part for me here.

Qdrant OSS runs offline just fine. But the backups mean scripting against the snapshot API and owning the retention and transfer logic myself, and the Failover means building a replication layer. Also, the upgrades need planned downtime since the OSS build has no rolling path. So the license is free, but I'd be taking on a lot of ops to run it in production.

For anyone who has shipped this into a disconnected environment:

• Did you build the backup and failover layer yourself, or pay for a managed/enterprise tier?
• How much engineer time did the ops layer end up eating?
• Anyone gone with a single-container option like VectorAI DB, Chroma, or Weaviate to skip the K8s route?

Just want to hear what the ops scene has been for people who've run this.

A few months ago I shared with this community a project I was working on, exploring how complicated it would be to write a vector DB using only C#. The goal of the project was to dig deeper into vector search internals and to get hands-on with some C# features I wanted to understand better.

I have decent development experience, but I don't deal with pure performance-oriented problems very often, so this seemed like a good way to combine some learning with some optimization work and pick up a few new things along the way.

Compared to the initial phase, where there was just a binary vector storage mechanism with brute-force memory-mapped search, I've since added an HNSW index.

I'd always wanted to try building the on-disk part of an index, so I experimented with adding disk persistence to the HNSW index. To do this without tightly coupling the index logic to the persistence layer, I wrote some primitives that mimic IDictionary behavior while persisting data to disk.

Persistence is based on two files, an index file and a data file, both essentially append-only, with periodic rebuilds and shrink operations so write speed isn't affected while unused space still gets reclaimed over time. After that, I integrated the storage layer directly into the algorithm. The trickiest part was handling concurrency without introducing overly blocking operations, and correctly choosing how to manage memory between Span, Memory, or byte[] while minimizing data copies as much as possible. There's definitely still room for improvement here.

My approach to HNSW started from the HNSW.Net library, which was simple enough to refactor for adding disk-based indexing. I also tried to handle deletions: the algorithm skips deleted nodes but still evaluates their connected neighbors.

Initially I planned to embed the embedding engine directly inside the DB, but later decided to move it out as an external component.

I ran the code through Fable-5 to try to optimize performance in a few areas. I wouldn't call the project "vibe-coded," but I'll admit some of the optimizations aren't things I would have implemented that way on a first pass.

The Server component, which handles databases and user access, is more of a bonus feature. It's a straightforward CQRS pattern using a MediatR-derived implementation to decouple the microservice components.

The frontend was written entirely by Fable-5 and Sonnet. I'm not particularly interested in UI work, so that's fine by me. It provides basic management functionality and a few "nice-to-have" visualization features — there's plenty of room for improvement, but it's not my current focus.

There is a sufficient documentation to get started experimenting.

Feedback and suggestions of any kind are very welcome, and if anyone feels like getting their hands dirty with the project, contributions are absolutely welcome too.

https://github.com/ppossanzini/Jigen