Show HN: Lantern – a PostgreSQL vector database for building AI applications (opens in new tab)

Although it doesn’t meet the definition of bribery it’s a similar concept. It’s trying to influence someone’s decision by personal gain rather than just what’s best for the company. DataDog used to do this (maybe they still do) where if you signed up for a trial they said you would get a 1 in 8 chance of getting an iPhone.

This is fine, its a standard enterprise marketing technique. Watch a webinar, get a gift card.

That’s like saying if the product is good it will stand on its own. So far the theory. As most founders here know it’s not so easy.

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!

> 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 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 updates as data is inserted and updated?

The HNSW algorithm updates the index after every insert. So all existing HNSW options (Lantern, pgvector, Neon, …) already support this.

With pgvector IVFFlat, you expect the performance to degrade over time, and you will need to re-index. This is because IVFflat’s index quality heavily depends on the centroids chosen at index creation time. HNSW does not have this limitation.

In both cases, you might want to do a full-index build to tune your hyperparameters.

We’re working on this in a few ways. One is automatic hyperparameter tuning. Another is supporting external index creation that would offload this to another server. Does this answer your question?

Pgvector builds a vector index.

Our extension, similarly, builds an index but also extends SQL in more ways.

For example,

- Generating embeddings to augment plain relational data

- Using data from local proprietary embedding models or third-party model APIs in queries.

We have more things planned like vector versioning, data retention policies and recall regression tracking.

> What does "without leaving your database" mean in this context?

You can work with embeddings with just SQL. For instance, a table of academic papers can be augmented with CLIP model embeddings produced locally. This entire process - creating, storing, and querying - happens using just SQL."

  SELECT abstract,
       introduction,
       figure1,
       clip_text(abstract) AS abstract_ai,
       clip_text(introduction) AS introduction_ai,
       clip_image(figure1) AS figure1_ai
  INTO papers_augmented
  FROM papers;

  SELECT 
    abstract, 
    introduction
  FROM papers_augmented
  ORDER BY abstract_ai <-> clip_text("The Foundation of the General Theory of Relativity")
  LIMIT 10;

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.)

Thanks!

I don’t believe pgvector reports performance changes between releases.

At the moment, we run the benchmarking on Github CI, but we plan to move this to an external machine, since the results are unstable on Github machines. We’re planning to extend benchmarking across other repos and versions.

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.

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!

Our index access method will be called lantern_hnsw if pgvector or any other provider has already taken the hnsw access method name.

btw, we did not create our own vector type and just use size-enforced real[] arrays to represent embeddings. However, you can use our index with pgvector's vector type. So, if you already have a table with pgvector's vector column type, you can start using Lantern by just creating an index on the same column.

We have not run microbenchmarks to see what dimension ranges perform best but those are coming soon! Below is an anecdotal answer:

We run our ci/cd benchmarks on 128dim sift vectors. We have some demos using clip embeddings (512dim) and baai/bge 768 dimensional embeddings.

Generally, smaller vectors allow higher throughput and result in smaller indexes. But the effect on performance is small. Once we merge the PR implementing vector element casts to 1 and 2 byte floats, the effect of this on throughput should be even smaller.

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?

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?

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

Not a Supabase user, but to my knowledge -- no. Except for a set of blessed extentions, Supabase only supports extensions that are written in "trusted languages" (ie. supported by pg_tle), and Lantern is written in C, which is currently not supported.

Postgres is love. Postgres is life.

PGaaS :D