[fakedang]

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?

[ngalstyan4]

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;

[saurik]

When you say "produced locally", do you mean on the client? If so, does this mean you require me to use some alternate PostgreSQL driver locally, parsing the SQL to add your one feature?

(If it is, this really feels like it should be a separate general purpose local extension mechanism into which random functions can be added, instead of something tied to this use case... maybe I want to add some locally-executed string parsing function, for example...)

(...but, the entire concept of having some functions be "locally" executed also feels really awkward/limited and will involve a ridiculous amount of work to make, at the end of the day, it only sort of work in some places in the query, so I bet you don't mean what I do when I say "locally", right?)

(But, like... doing it remotely--on the database server as part of the query plan--frankly seems kind of crazy to me, as it is going to be so slow and add a massive CPU load to what should be an I/O workload. Makes for good demos I bet, but otherwise unusable in a database context.)

(Regardless, the premise of seeing this as a feature kind of squicks me... like, it honestly gives me strong apprehensions about using your extension at all, as I can see--very clearly--the mission creep it is going cause as you deal with demands to drag more and more popular embedding models with lots of execution dependencies as part of the extension that has to be loaded into the server, as well as fielding distracting discussions about the performance of the embedding helpers...)

(...this frankly shouldn't be part of the same extension: it should be another extension that happens to return this extensions data type--or even potentially returns some more generic one, like an array of float, making it drop-in compatible with other extensions for vector indexing--and there should then almost certainly be separate such extensions for each major model you want to support.)

[ngalstyan4]

>When you say "produced locally", do you mean on the client?

Sorry for the confusion. By “produced locally” I meant “produced on your DB server” as opposed to being an API call to a third party service such as OpenAI or HuggingFace.

(But, like... doing it remotely--on the database server as part of the query plan--frankly seems kind of crazy to me, as it is going to be so slow and add a massive CPU load to what should be an I/O workload. Makes for good demos I bet, but otherwise unusable in a database context.)

It seems like you’re worried about these workflows being on the Postgres server, which may lead to performance issues.

However, if performance becomes an issue, the functions can be executed on another server. In this approach, whether or not the functions run on the Postgres server, the end user gets access to a better developing experience as all the functions they need are available within SQL.

>...this frankly shouldn't be part of the same extension We agree. These functions are already in another repository, and not part of the same extension. The repository is here: https://github.com/lanterndata/lantern_extras

[simonw]

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

[jeungsp]

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.