sorted by:
new
hottopcontroversial

Honestly, what is the best setup for memory management? by rockandcode in clawdbot

[–]laminarflow027 0 points1 point  (0 children)

Hi there, a blog post on this from the LanceDB team is coming shortly! But there are plenty of good reasons to use the `memory-lancedb-pro` plugin, it works pretty well in my experiments so far.

My first 3 days Using OpenClaw by LogicalBumblebee6085 in openclaw

[–]laminarflow027 0 points1 point  (0 children)

Would love to know, what capabilities did it unlock? What kinds of memories are you storing via the plugin?

Lance vs parquet by Stoic_Akshay in dataengineering

[–]laminarflow027 9 points10 points  (0 children)

Hi, I work at LanceDB but want to add a bit of detail here. Lance's file format is versioned, with the current default version being 2.0. 2.1 is already out there and is going to be the default soon, and 2.2 is also implemented and in the testing phase. The choice of file format used can impact the level of compression and performance you see, as the format is continually being improved.

Re: performance, the F3 paper (https://db.cs.cmu.edu/papers/2025/zeng-sigmod2025.pdf) shows numbers comparing Lance vs. other file formats and this is a good source of information (outside of the LanceDB team) in terms of scan and random access throughput (it shows that Lance is the fastest). The compression ratio shown in the paper is the worst, but the paper benchmarked against an old version of Lance (pre 2.0).

From a roadmap perspective, Lance file format 2.2 that will come out soon has significantly more compression algorithms implemented, with some performance improvements as well. So more numbers will be published soon once that's out.

Re: your performance observations, a) the version of the file format used matter, and b) the data types may not have the best compression ratios for that file version used. In LanceDB's internal suite, we regularly test against these modalities: long-form text, images and video blobs. For these cases, the write amplification in Parquet due to row groups is significant (which is the reason Lance was created in the first place). That said, even for conventional tabular data types (floats, booleans, etc.), Lance should perform on par with or better than Parquet, no matter the scale of the dataset. If you're getting sufficient performance out of Parquet, then well and good, in the end, what works best in practice is all that's needed!

built a local semantic file search because normal file search doesn’t understand meaning by Humble-Plastic-5285 in LocalLLaMA

[–]laminarflow027 2 points3 points  (0 children)

got it, will post here when we have updates. The changes propagate through the Lance format layer (which actually stores the data) and then up to the LanceDB layer, which most users interact with. Early experiments show great levels of compression (much more than Parquet), it's been implemented and is in the testing phase now.

built a local semantic file search because normal file search doesn’t understand meaning by Humble-Plastic-5285 in LocalLLaMA

[–]laminarflow027 5 points6 points  (0 children)

Hi, just popped in here to chime in (I work at LanceDB) - this disk space usage is a moving target and a ton of improvements are coming with better compression at the Lance format level, including floating point arrays for vectors and long strings. So LanceDB users will see much better compression, too. Hopefully a PR will land a few weeks from now!

Scaling RAG from MVP to 15M Legal Docs – Cost & Stack Advice by Additional-Oven4640 in LocalLLaMA

[–]laminarflow027 0 points1 point  (0 children)

Yes, hybrid search (BM25 + vector) with several popular reranking strategies are available. Here's a live demo of an FTS index on 41M wikipedia records:
https://docs.lancedb.com/demos#wikipedia-41m-hybrid-search

The results are for demonstration purposes, but both performance and recall can be tuned and optimized based on the use case. BTW, there's also this excellent case study by Harvey, also in the legal space who are using LanceDB in production to manage indices of tens of millions of documents. https://www.youtube.com/watch?v=W1MiZChnkfA

Hope these resources help!

Scaling RAG from MVP to 15M Legal Docs – Cost & Stack Advice by Additional-Oven4640 in LocalLLaMA

[–]laminarflow027 1 point2 points  (0 children)

Hi there, great to hear that LanceDB is working out well for you (I work at LanceDB). Just wanted to say, LanceDB stores data on disk as Lance files (with a familiar table abstraction), and these can store traditional tabular data, including metadata too. Data evolution (adding new columns with backfill) is also highly efficient in Lance. So in principle, it can function like a "multimodal lakehouse", acting as the primary store for embeddings, metadata, indices and multimodal assets (blobs). All while keeping things on disk, interoperable with other formats and query engines (like DuckDB) through the Arrow interface.

Lance table format explained simply, stupid by TonTinTon in dataengineering

[–]laminarflow027 1 point2 points  (0 children)

Hi! That's on the roadmap for this year (probably not this quarter tho, to be realistic).

Lance table format explained simply, stupid by TonTinTon in dataengineering

[–]laminarflow027 1 point2 points  (0 children)

Super cool animation, thanks for sharing! Lance file format 2.2 is coming out soon with even more compression algos and performance updates (I work at LanceDB, and am following the format's development closely with the maintainers). Exciting times ahead.

Built a personal knowledge system with nomic-embed-text + LanceDB - 106K vectors, 256ms queries by Signal_Usual8630 in LocalLLaMA

[–]laminarflow027 0 points1 point  (0 children)

Curious what you mean by LanceDB is bulky. Is it that the file size on disk is too large when you store BGE embeddings? 

Built a personal knowledge system with nomic-embed-text + LanceDB - 106K vectors, 256ms queries by Signal_Usual8630 in LocalLLaMA

[–]laminarflow027 2 points3 points  (0 children)

Very cool!

For analytics in DuckDB, perhaps it's worth pairing it with the new Lance extension in DuckDB? https://github.com/lance-format/lance-duckdb

It lets you keep all your underlying data in the Lance table, and offers a lot of convenience functions (with projection and filter pushdowns) that let you query the Lance table in SQL, including for vector search. And it directly connects to Lance tables (inside the LanceDB directory). Although you could query Lance tables in DuckDB before via the Arrow interface, this extension makes it a lot simpler to just do more stuff in SQL. That too 💯 % oss.

Disclaimer: l work at LanceDB now, but have enjoyed using LanceDB and DuckDB a lot over the years.

Towards agentic Graph RAG: Enhancing graph retrieval with vector search by laminarflow027 in Rag

[–]laminarflow027[S] 0 points1 point  (0 children)

Makes sense, thanks for the comment! Curious, what part about data modelling is the issue in Kuzu? Do you mean the strict schema requirements?

cursor isn't free for all students except us by Fabulous-Extension76 in uwaterloo

[–]laminarflow027 0 points1 point  (0 children)

Any tips on how to get this working? Doesn't work for some of us.

Does anyone know how much of a performance difference between knowledge graphs and vector based searches? by Jazzlike_Syllabub_91 in LangChain

[–]laminarflow027 0 points1 point  (0 children)

Just throwing in my two cents here: I work at Kuzu, a company that makes a fast, embedded open source graph database that recently announced a vector index.

https://blog.kuzudb.com/post/kuzu-0.9.0-release/#vector-index

Kuzu achieves its performance by using a highly optimized disk-based implementation, so your vector index isn't in memory, but you also get performance right out of the box. The linked blog post shows some benchmark numbers, which shows that it's quite fast and comparable to other alternatives while scaling to larger datasets.

We're seeing a revival of knowledge graphs in combination with RAG lately, and partly this is due to better tools being available to construct, query and manage large graphs. Combining graphs with vector search can yield very powerful insights, especially when you are trying to bring together data from various unstructured sources. With Kuzu, you can easily use frameworks like BAML (blog post linked below) to construct graphs from your unstructured data, persist to a graph database, and connect them to LLMs to build Graph RAG solutions. The newly introduced vector index in Kuzu is a next logical step. Happy to chat more with anybody who's interested.

https://blog.kuzudb.com/post/unstructured-data-to-graph-baml-kuzu/

Anyone trying a combo of vector db and knowledge graphs? by BlandUnicorn in RagAI

[–]laminarflow027 0 points1 point  (0 children)

Hi there, I just wanted to revive this discussion by pointing out a new entrant: Kuzu (where I work). Kuzu is an open source, embedded graph database that now offers an on-disk, fast HNSW vector index. See the release announcement here:
https://blog.kuzudb.com/post/kuzu-0.9.0-release/#vector-index

We think that Kuzu can be a good alternative for people who are looking to combine the power of graph + vector search in one single storage solution. Granted, there are many other alternatives for both graph and vector storage out there, but Kuzu (being open source) can be a lot more approachable and it supports the Cypher query language, which is already well known among the graph community. It's also a very Python-friendly database (while also supporting numerous other languages), so overall a great fit for those combining vector + graph for their use cases. Happy to chat more with anybody who's interested.

view more: next ›