by ngalstyan4 on 9/13/23, 5:41 PM with 43 comments
We have the most complete feature set of all the PostgreSQL vector database extensions. Our database is built on top of usearch — a state of the art implementation of HNSW, the most scalable and performant algorithm for handling vector search.
There’s three key metrics we track. CREATE INDEX time, SELECT throughput, and SELECT latency. We match or outperform pgvector and pg_embedding (Neon) on all of these metrics.
** Here’s what we support today **
- Creating an AI application end to end without leaving your database (example: https://github.com/ezra-varady/lanterndb-semantic-image-sear...)
- Embedding generation for popular use cases (CLIP model, Hugging Face models, custom model)
- Interoperability with pgvector's data type, so anyone using pgvector can switch to Lantern
- Parallel index creation capabilities -- Support for creating the index outside of the database and inside another instance allows you to create an index without interrupting database workflows.
** Here’s what’s coming soon **
- Cloud-hosted version of Lantern
- Templates and guides for building applications for different industries
- Tools for generating embeddings (support for third party model API's, more local models)
- Support for version control and A/B test embeddings
- Autotuned index type that will choose appropriate index creation parameters
- 1 byte and 2 byte vector elements, and up to 8000 dimensional vectors support
** Why we started Lantern today **
There's dozens of vector databases on the market, but no enterprise option built on top of PostgreSQL. We think it's super important to build on top of PostgreSQL
- Developers know how to use PostgreSQL.
- Companies already store their data on PostgreSQL.
- Standalone vector databases have to rebuild all of what PostgreSQL has built for the past 30-years, including all of the optimizations on how to best store and access data.
We are open source and excited to have community contributors! Looking forward to hearing your feedback!
by bryan0 on 9/13/23, 10:56 PM
> Book some time here, and we will help switch you over for FREE and get you a pair of FREE AirPods Pro
This just comes off as sketchy to me. If the tech is good it will stand on its own.
by carlossouza on 9/13/23, 8:14 PM
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 HNSW, no IVFFLAT.
What would be Lantern's performance for this specific use case?
Thx!
by simonw on 9/13/23, 6:55 PM
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 updates as data is inserted and updated?
Just had a thought: maybe I could handle this case by maintaining an index of every existing vector, then tracking rows that have been created since that index itself.
Then I could run an indexed search that returns the top X results + their distance scores, then separately do a brute-force calculation of scores just for the small number of rows that I know aren't in the index - and then combine those together.
Would that work OK?
Even if the index doesn't return the scores directly, if it gives me the top 20 I could re-calculate distance scores against those 20 plus the X records that have been inserted since the index was creation and return my own results based on that.
by ezra-varady on 9/13/23, 9:36 PM
And code can be found at
by fakedang on 9/13/23, 6:40 PM
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?
by ashvardanian on 9/13/23, 7:47 PM
I also love your specialized CI! Pgvector probably doesn’t report performance changes between releases, or does it? Was it easy to implement? Do you run the whole eval on GitHub?
by howon92 on 9/13/23, 6:59 PM
by mattashii on 9/13/23, 8:36 PM
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.
by skeptrune on 9/21/23, 2:31 AM
by loxias on 9/14/23, 2:52 AM
by raoufchebri on 9/13/23, 7:37 PM
CREATE INDEX semantic_image ON image_table USING hnsw (v dist_cos_ops) WITH (M=5, ef=30, ef_construction=30, dims=512);
by jw903 on 9/14/23, 1:50 AM
by dalberto on 9/13/23, 9:01 PM
by swalsh on 9/13/23, 8:50 PM
by justanotheratom on 9/13/23, 7:54 PM
by consoomer on 9/13/23, 7:35 PM
Wait, PostgREST already does...
builds entire SaaS with Postgres