My main use case for
Supabase Vector is converting PDF files into chunks and then creating embeddings for those chunks and storing them in
Supabase Vector.
We have long PDF files we need to process, and then we need to ask questions and get answers on those files. My main usage is RAG for chats on PDFs, because models have limited memory in context, so less token usage and processing a large amount of data with question and answering capability.
I have been using Supabase Vector mostly for RAG. I have been using it for when a user is doing a lot of chats back and forth, and it is not useful to put all of the chat into the context of the LLM. I use it for chats on PDFs, and where I do not want to process and waste tokens.
The best features that Supabase Vector offers include native vector storage in
PostgreSQL. I do not need to switch entirely to a vector database because in the
PostgreSQL database, I can do other things as well, such as storing relational data and other tables.
In the same database I can utilize the embeddings and vectors provided by PG Vector. Additionally, Supabase Vector is a managed service, so I do not need to worry about scaling the database and managing the infrastructure. I can be up and running with Supabase Vector within a few seconds. The other valuable feature is semantic search, which I can do via PG Vector.
The managed service that Supabase Vector offers makes my workflow easier because I do not need to worry about managing the infrastructure or scaling the database. If I have an app idea and come up with a great app idea and I need to prototype and then push that idea into the market, I do not have to care about the infrastructure or scaling. In an instant, I get the managed Supabase Vector service available via the APIs, and then I just need to focus on my product.
The semantic search feature helps me specifically when working with my PDFs and chat use case because it is one of the core techniques behind modern AI chat systems and knowledge base assistants. Traditional keyword search may fail when words are different even though the meaning is nearly identical. For example, imagine a PRD that states the platform must support employee shift swapping with manager approval. When a user asks can workers exchange shifts, a keyword search may fail because exchange is not equal to swap and workers is not equal to employees. Instead of storing words, Supabase Vector stores embeddings, a vector.
An embedding is a list of numbers representing the meaning of text. When a user asks can workers exchange shifts, the system converts the question into the embedding and searches for nearby embeddings to find the PRD section about shift swapping and returns it to the LLM. The LLM now answers using the relevant section. If I have a 200-page PRD for my workforce management SaaS, chunking the document and generating the embeddings and then finding the closest chunk automatically gives me the meaning. It automatically searches for employees even though the query asks for workers. It really captures meaning instead of straightforward word-to-word search.
Supabase Vector positively impacts my organization by reducing the cost of the LLMs. Prior to using vector and RAG, I was giving whole chats to the LLM, and the LLM was processing the whole context and maintaining context. There is a limit in the LLMs of 1 million to 200,000 tokens I can process. With Supabase Vector, I have really reduced the cost and token consumption as well.
I do not have metrics in my mind right now, but I can look into the metrics and provide an answer.
I do not have anything in my mind right now, but I can get back with this answer.
I do not have anything in my mind, but I will get back when I have more information.
I have been using Supabase Vector for roughly two years.
I do not have additional thoughts. My overall review rating for Supabase Vector is 8 out of 10.