Lance table format explained simply, stupid (Animated)(tontinton.com)
tontinton.com
Lance table format explained simply, stupid (Animated)
https://tontinton.com/posts/lance/
6 comments
My experience trying LanceDB has been abysmal. It worked great on dev and small testing environments but as soon we tried production workloads it would get extremely slow. We shifted to PostgreSQL + pgvector and had absolutely no issues, even if it is not "engineered for multimodal data". Maybe we were doing something wrong but we did put effort in trying to make it work - it is this hard to get it performant?
I’m also curious to hear what challenges you encountered. I’ve used LanceDB for a few projects in production now and it’s worked out reasonably well.
The docs quality is spotty, and the lack of parity between the async and sync python API is frustrating, but otherwise it’s been great.
The only performance issues I’ve had have been A) not rebuilding indexes on an appropriate cadence, B) not filtering the search space enough for queries which bypass the index, or C) running search against millions of vectors on an object storage and expecting millisecond latency.
The docs quality is spotty, and the lack of parity between the async and sync python API is frustrating, but otherwise it’s been great.
The only performance issues I’ve had have been A) not rebuilding indexes on an appropriate cadence, B) not filtering the search space enough for queries which bypass the index, or C) running search against millions of vectors on an object storage and expecting millisecond latency.
Great, thanks for the feedback! I work at LanceDB and will take these points into account (esp. the docs).
Curious what performance issues you faced. Was that in OSS LanceDB? And what were the challenges?
Inserts become increasingly slow. Became >10sec for a chat completion insert after 10_000 entries on k8s Longhorn atop NVMe.
Cool animations. Does anyone know how they made those animations? Or did they do it with vanilla JS/CSS/HTML?