Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Lantern – a PostgreSQL vector database for building AI applications

docs.lantern.dev

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Show HN: Lantern – a PostgreSQL vector database for building AI applications

#21

Post by simonw »

diqi wrote: post #18
simonw wrote: post #3

"There's three key metrics we track. CREATE INDEX time, SELECT throughput, and SELECT latency." There's a fourth metric that I'm really interested in: assuming it's possible, how long does it take to update the index with just one or two updated or inserted vectors? Is the expectation with this (and the other) tools that I'll do a full index rebuild every X minutes/hours, or do some of them support ongoing partial up…

> There's a fourth metric that I'm really interested in: assuming it's possible, how long does it take to update the index with just one or two updated or inserted vectors? Here’s a chart for INSERT latency (sorry about the formatting): https://docs.lantern.dev/graphs/insert.png At the moment, we underperform Neon wrt this metric, but a better implementation is coming soon that will address this. > Is the expectation…

That's really useful, thanks.

Re: Show HN: Lantern – a PostgreSQL vector database for building AI applications

#22

Post by jeungsp »

simonw wrote: post #4
fakedang wrote: post #2

This might be a noob question but what does Lantern have that a normal Postgres dB with pgvector does not? I think Supabase already has a Postgres as a service product with the pgvector extension too. Second: >Creating an AI application end to end without leaving your database (example: https://github.com/ezra-varady/lanterndb-semantic-image-sear ...) What does "without leaving your database" mean in this context?

I assume that question - Lantern v.s. pgvector - is meant to be answered by those performance graphs: Lantern is a bit faster. (I'd find those graphs easily to quickly understand if they had a "lower is better"/"higher is better" note on each one.)

Hi, Jeung here, one of the co-founders of Lantern.

You’re right. Our performance is just a bit faster today.

We expect everyone’s performance to continue to improve, but we have lots of improvements coming soon, and we plan to continue to widen the lead.

But there are more important reasons to use Lantern besides performance. If you look at our features list and what’s coming soon, we are looking to create tools that make for better applications and better developer experience.

Re: Show HN: Lantern – a PostgreSQL vector database for building AI applications

#24

Post by diqi »

mattashii wrote: post #19

How do you do cleanup of the index during VACUUM? And, do you have recall-vs-qps graphs like those on https://ann-benchmarks.com/ ? Those are generally more apples-to-apples, as 100k rows isn't exactly a reputable benchmark.

We don’t do cleanup of the index during VACUUM yet. That said, it’s coming very soon. We’re built on top of Usearch, which supports deletes. We plan to work with the Usearch team to port the post performant deletes to Lantern, and thereby support VACUUM.

With respect to recall vs QPS, we went ahead and generated this plot, hope this is helpful? http://docs.lantern.dev/graphs/recall-tps.png

You're right, 100k rows isn’t a reputable benchmark. We wanted to launch very quickly, and have benchmarking for larger datasets coming soon. Benchmarking is baked into our CI/CD, we take it very seriously!

Re: Show HN: Lantern – a PostgreSQL vector database for building AI applications

#25

Post by ngalstyan4 »

carlossouza wrote: post #16

I'm using pgvector in production, mainly in a table with 500k-1M rows. My main use case is to return search results with pagination : page 1 from 1-50, page 2 from 51-100, page 3 from 101-150, etc. (Think LIMIT and OFFSET). After a lot of experimentation and help from pgvector's team, we discovered that, for this specific use case, IVFFLAT index is much faster than HNSW. I looked at your documentation and only saw HN…

This sounds like a very useful feature, and we will prioritize this.

You’re correct that IVFFLAT would be faster for your use case. However, IVFFLAT’s shortcoming is bad recall, which means less relevant results for your application. We believe that our HNSW implementation (or other indexes) can handle use cases like yours.

We currently handle a similar use-case by rerunning our index searches with exponentially increasing LIMITs and dropping the results which are not needed. Could you send us an email at support@lantern.dev? We can generate the numbers by this weekend, and get back to you with concrete results.

By the way – not sure if you saw in our blog post, if you’re using pgvector in production and switch to Lantern, we’ll help you every single step of the way. It’s very quick, and we’ll also send you some free AirPods Pro at the end of it!

Re: Show HN: Lantern – a PostgreSQL vector database for building AI applications

#27

Post by jeungsp »

howon92 wrote: post #5

Congrats on the launch!!! I suggest you highlight "why lantern is better than pgvector" at the top of your page. The first thing that came to my mind after reading this was "why should I use this instead of pgvector?"

This is a great idea. We will have lots of content in the days ahead to talk about why people should make the switch.

Do you use pgvector now? Would love to switch you over.

Re: Show HN: Lantern – a PostgreSQL vector database for building AI applications

#28

Post by diqi »

justanotheratom wrote: post #15

can I use this in Supabase?

Unless Supabase decides to integrate Lantern (currently they integrate pgvector) you unfortunately cannot use Lantern with Supabase.

That said, we will offer Lantern Cloud, our own hosted postgres offering (very soon. Happy to keep you in the loop. If you’re interested, please feel free to join the waitlist here: https://forms.gle/PouJxAWiSa63udJW8

Re: Show HN: Lantern – a PostgreSQL vector database for building AI applications

#29

Post by jeungsp »

dalberto wrote: post #26

Any plans to support sparse vectors?

We’re built on top of Usearch, which will very soon support sparse vectors. We’re working with them to make sure it also works in Lantern.

Can you tell me more about your use case?

Re: Show HN: Lantern – a PostgreSQL vector database for building AI applications

#30

Post by jeungsp »

swalsh wrote: post #23

I like how easy postgresql vector is to use, but scaling up seems to get pretty expensive when comapred to something like qdrant.

Nothing fundamentally stops a postgres implementation being equally performant as something like Qdrant.

Fundamentally, an index’s performance is based on the hardware and the algorithm and the quality of implementation. Any optimizations Qdrant can make, we can also make.

We will be benchmarking ourselves against all of the other standalone database options as well and we’ll be working to try and outperform them. Excited to share those once we have them.

We are curious – what are you most concerned about? SELECT time? INDEX size? Latency? Throughput?

Post reply on HN