Check out Unum’s usearch. It beats anything, and is super easy to use. It just does exactly what you need. https://github.com/unum-cloud/usearch
Have you tested it against Lance? Does it do predicate pushdown for filtering?
The best way to use text embeddings portably is with Parquet and Polars
11–20 of 61 posts
Re: The best way to use text embeddings portably is with Parquet and Polars
#12Since we are talking about an embedded solution shouldn't the benchmark be something like sqlite with a vector extension or lancedb?
My natural point of comparison without actually be DuckDB plus their vector search extension.
Re: The best way to use text embeddings portably is with Parquet and Polars
#13To the second footnote: you could utilize Polar's lazyframe API to do that cosine similarity in a streaming fashion for large files.
Re: The best way to use text embeddings portably is with Parquet and Polars
#14Check out Unum’s usearch. It beats anything, and is super easy to use. It just does exactly what you need. https://github.com/unum-cloud/usearch
Have you tested it against Lance? Does it do predicate pushdown for filtering?
Usearch is a vector store afaik, not a vector db. At least that’s how I use it.
I haven’t compared it to lancedb, I reached for it here because the author mentioned Faiss being difficult to use and install. usearch is a great alternative to Faiss.
But thanks for the suggestion, I’ll check it out
Re: The best way to use text embeddings portably is with Parquet and Polars
#15For another library that has great performance and features like full text indexing and the ability to version changes I’d recommend lancedb https://lancedb.github.io/lancedb/ Yes, it’s a vector database and has more complexity. But you can use it without creating indexes and it has excellent polars and pandas zero copy arrow support also.
Since a lot of ML data is stored as parquet, I found this to be a useful tidbit from lancedb's documentation:
> Data storage is columnar and is interoperable with other columnar formats (such as Parquet) via Arrow
https://lancedb.github.io/lancedb/concepts/data_management/
Edit: That said, I am personally a fan of parquet, arrow, and ibis. So many data wrangling options out there it's easy to get analysis paralysis.
Re: The best way to use text embeddings portably is with Parquet and Polars
#16Polars + Parquet is awesome for portability and performance. This post focused on python portability, but Polars has an easy-to-use Rust API for embedding the engine all over the place.
Re: The best way to use text embeddings portably is with Parquet and Polars
#17Is your example of a float32 number correct, holding 24 ascii char representation? I had thought single-precision gonna be 7 digits and the exponent, sign and exp sign. Something like 7+2+1+1 or 10 char ascii representation? Rather than the 24 you mentioned?
One of the things I remember from my PhD work is that you can do a stupendous number of FLOPs on floating point numbers in the time it takes to serialize/deserialize them to ASCII.
Re: The best way to use text embeddings portably is with Parquet and Polars
#18To the second footnote: you could utilize Polar's lazyframe API to do that cosine similarity in a streaming fashion for large files.
That would get around memory limitations but I still think that would be slow.
Re: The best way to use text embeddings portably is with Parquet and Polars
#19Nice read. I agree that for a lot of hobby use cases you can just load the embeddings from parquet and compute the similarities in-memory.
To find similarity between my blogposts [1] I wanted to experiment with a local vector database and found ChromaDB fairly easy to use (similar to SQLite just a file on your machine).
Re: The best way to use text embeddings portably is with Parquet and Polars
#20To the second footnote: you could utilize Polar's lazyframe API to do that cosine similarity in a streaming fashion for large files.
That would get around memory limitations but I still think that would be slow.
You'd be surprised. As long as your query is using Polars natives and not a UDF (which drops it down to Python), you may get good results.