[dead]
90x Faster Than Pgvector – Lantern's HNSW Index Creation Time
21–30 of 39 posts
Re: 90x Faster Than Pgvector – Lantern's HNSW Index Creation Time
#22This reads like a marketing piece, not an honest technical blogpost.
I agree that Usearch is fast, but it feels pretty dishonest to take credit for someone else's work. Like maybe at least honestly profile what's going on with USearch vs pgvector (..and which settings for pgvector??), and write something interesting about it?
The last time I tried Lantern, it'd segfault when I tried to do anything non-trivial with it, and was incredibly unsafe with how it handled memory. Hopefully that's at least fixed.. but lantern has so many red flags.
Re: 90x Faster Than Pgvector – Lantern's HNSW Index Creation Time
#23Earlier quoted context omitted.
That sounds much longer than it should. I am not sure on your exact use-case but I would encourage you to check out Marqo ( https://github.com/marqo-ai/marqo - disclaimer, I am a co-founder). All inference and orchestration is included (no api calls) and many open-source or fine-tuned models can be used.
> That [pgvector index creation time] sounds much longer than it should... I would encourage you to check out Marqo Your comment makes it sound like Marqo is a way to speed up pgvector indexing, but to be clear, Marqo is just another Vector Database and is unrelated to pgvector.
Fair enough, apologies for the confusion!
Re: 90x Faster Than Pgvector – Lantern's HNSW Index Creation Time
#24This reads like a marketing piece, not an honest technical blogpost. I agree that Usearch is fast, but it feels pretty dishonest to take credit for someone else's work. Like maybe at least honestly profile what's going on with USearch vs pgvector (..and which settings for pgvector??), and write something interesting about it? The last time I tried Lantern, it'd segfault when I tried to do anything non-trivial with it…
Hi, sorry that you didn't have a good experience with Lantern before. We first posted in HN about 3 months ago - Things should be better now, please let us know if you have any issues.
Re: 90x Faster Than Pgvector – Lantern's HNSW Index Creation Time
#25So approximately 0% chance I could use this on AWS RDS or Aurora correct? Still, very impressive
Likely as an extension eventually. I know RDS has a variety of postgres extensions you can use. Pg_vector is supported, so likely lantern could get support as well. [1] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Postg...
Unless AWS is going to buy a license, which is probably going to cost them a ton of money, I don't seem them offering Lantern given its licensed under the Business Source License, which is nasty for cloud providers.
AWS is also a big proponent of pgvector, so it is more likely they would put more money into that, in my non-expert opinion.
Re: 90x Faster Than Pgvector – Lantern's HNSW Index Creation Time
#26This reads like a marketing piece, not an honest technical blogpost. I agree that Usearch is fast, but it feels pretty dishonest to take credit for someone else's work. Like maybe at least honestly profile what's going on with USearch vs pgvector (..and which settings for pgvector??), and write something interesting about it? The last time I tried Lantern, it'd segfault when I tried to do anything non-trivial with it…
Using ivfflat is much faster for bulk index creation than lantern. There are a lot of trade offs depending on what everyone's specific use case is, but it seems like a pretty massive thing to leave out.
``` postgres=# CREATE INDEX ON sift USING ivfflat (v vector_l2_ops) WITH (lists=1000); CREATE INDEX Time: 65697.411 ms (01:05.697) ```
Re: 90x Faster Than Pgvector – Lantern's HNSW Index Creation Time
#27This reads like a marketing piece, not an honest technical blogpost. I agree that Usearch is fast, but it feels pretty dishonest to take credit for someone else's work. Like maybe at least honestly profile what's going on with USearch vs pgvector (..and which settings for pgvector??), and write something interesting about it? The last time I tried Lantern, it'd segfault when I tried to do anything non-trivial with it…
Using ivfflat is much faster for bulk index creation than lantern. There are a lot of trade offs depending on what everyone's specific use case is, but it seems like a pretty massive thing to leave out. ``` postgres=# CREATE INDEX ON sift USING ivfflat (v vector_l2_ops) WITH (lists=1000); CREATE INDEX Time: 65697.411 ms (01:05.697) ```
cofounder here.
You are right that there are many trade-offs between HNSW and IVFFLAT.
E.g. IVFFLAT requires there be significant amount of data in the table, before the index is created, and assumes data distribution does not change with additional inserts (since it chooses centroids during the initial creation and never updates them)
We have also generally had harder time getting high recall with IVFFLAT on vectors from embedding models such as ada-002.
There are trade-offs, some of which we will explore in later blog posts.
This post is about one thing - HNSW index creation time across two systems, at a fixed 99% recall.
Re: 90x Faster Than Pgvector – Lantern's HNSW Index Creation Time
#28Earlier quoted context omitted.
Using ivfflat is much faster for bulk index creation than lantern. There are a lot of trade offs depending on what everyone's specific use case is, but it seems like a pretty massive thing to leave out. ``` postgres=# CREATE INDEX ON sift USING ivfflat (v vector_l2_ops) WITH (lists=1000); CREATE INDEX Time: 65697.411 ms (01:05.697) ```
cofounder here. You are right that there are many trade-offs between HNSW and IVFFLAT. E.g. IVFFLAT requires there be significant amount of data in the table, before the index is created, and assumes data distribution does not change with additional inserts (since it chooses centroids during the initial creation and never updates them) We have also generally had harder time getting high recall with IVFFLAT on vectors…
External index creation also requires that a significant amount of data be in the table for it to be worth it, along with all the other potential issues.
Re: 90x Faster Than Pgvector – Lantern's HNSW Index Creation Time
#29Earlier quoted context omitted.
Likely as an extension eventually. I know RDS has a variety of postgres extensions you can use. Pg_vector is supported, so likely lantern could get support as well. [1] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Postg...
Unless AWS is going to buy a license, which is probably going to cost them a ton of money, I don't seem them offering Lantern given its licensed under the Business Source License, which is nasty for cloud providers. AWS is also a big proponent of pgvector, so it is more likely they would put more money into that, in my non-expert opinion.
Adding to this, the article the GP comment has linked to is for Trusted Language Extensions, which would allow AWS users to run extensions that aren't "officially" installed on RDS
however, since Latern is written in C++, it is not a Trusted Language for Postgres. If they instead used Rust (for example), then it would theoretically be able to be used with RDS, since Rust is now a Trusted Language on RDS: https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-rd...
Re: 90x Faster Than Pgvector – Lantern's HNSW Index Creation Time
#30Earlier quoted context omitted.
Unless AWS is going to buy a license, which is probably going to cost them a ton of money, I don't seem them offering Lantern given its licensed under the Business Source License, which is nasty for cloud providers. AWS is also a big proponent of pgvector, so it is more likely they would put more money into that, in my non-expert opinion.
Adding to this, the article the GP comment has linked to is for Trusted Language Extensions , which would allow AWS users to run extensions that aren't "officially" installed on RDS however, since Latern is written in C++, it is not a Trusted Language for Postgres. If they instead used Rust (for example), then it would theoretically be able to be used with RDS, since Rust is now a Trusted Language on RDS: https://aws…
My understanding is Trusted Language Extensions refer to extensions written in PL/Rust - a Postgres extension mechanism to write user defined functions and use them in SQL queries.
PL/Rust is a more performant and more feature-rich alternative to PL/pgSQL, which is the traditional UDF scripting language for Postgres.
Building a vector index (or any index for that matter) inside Postgres is a more involved process and can not be done via the UDF interface, be it Rust, C or PL/pgSQL.
So, I think even if Lantern was written in Rust, it would not be a Trusted Language Extension under this definition.