Supabase uses pgvector as an extension to Postgres for storing, indexing, and retrieving embeddings alongside application data.
2
Adding the HNSW index improved both query throughput and accuracy in the benchmark discussed, addressing an earlier criticism of pgvector.
3
Postgres features such as partitions, triggers, row-level security, and extensions support practical AI application designs, including filtering and isolating embedding data.
Summary
Paul Copplestone explains why Supabase uses pgvector and why he expects Postgres to remain useful for many AI applications. Supabase provides a full Postgres database alongside authentication, edge functions, storage, realtime features, and vector support. Copplestone describes how Greg Brockman? contributed pgvector to Supabase, then shows how its use grew through applications such as documentation search. He responds to a benchmark that criticized pgvector by describing the addition of HNSW and a comparison with Pinecone. His strongest example uses Postgres partitions and triggers to separate good and bad image embeddings before indexing them. He also points to row-level security and the ability to fetch operational data and embeddings in one database round trip. Supabase is working on sharding with Citus for workloads containing billions of vectors. Copplestone still expects specialized vector databases to have room where they provide capabilities outside Postgres.
Supabase gives AI applications vector storage inside a broader Postgres platform
Copplestone introduces Supabase as a backend service that gives each project a full Postgres database. It also provides authentication, edge functions powered by Deno, file storage, realtime features, and vector support powered by pgvector. Authentication users and file directory structures can live in the database, so developers can apply database access rules to them. Supabase is open source, with its work licensed under MIT, Apache 2, or Postgres licenses. Copplestone says the company supports existing communities, which is why it contributes to and builds around pgvector rather than creating an entirely separate vector system.
A community contribution turned pgvector into a practical Supabase feature
The pgvector story began with an email from Greg, who asked whether Supabase would accept his Postgres extension for vector operations. Copplestone merged the extension and then asked Greg to help fix Supabase's broken documentation search. Two weeks later, the team released Clippy, an AI documentation search assistant that developers could use as a template for their own docs. Other projects followed, including an MDN version from Milla. Copplestone connects this early example to Supabase's later growth in AI applications and says pgvector became part of the stack used by many builders.
Supabase saw rapid adoption of pgvector among newly created databases
Copplestone says Supabase was launching around 12,000 databases each week at the time of the talk, with roughly 10 to 15 percent using pgvector in some way. That meant thousands of AI applications were being launched weekly. He describes applications built quickly and then scaled to large user bases, including one that reached a million users in 10 days after being built in three days. The application used by the audience was also powered by Supabase. Greg, who originally proposed the extension, later joined Supabase and led a workshop at the event.
Adding HNSW addressed a public criticism of pgvector's speed and accuracy
Copplestone responds to a post arguing that pgvector was unsuitable for production because it was slower and less accurate than a dedicated vector database. He says the criticism mischaracterized Supabase because Andrew Kane originally owned and developed pgvector independently, although Supabase contributes to it. After seeing the post, Andrew worked with the Qdrant and AWS teams to add HNSW support. Copplestone says the work took about a month. In the benchmark he presents, the HNSW version increased queries per second and accuracy compared with the earlier Postgres IVF flat index, reaching 0.99 for both Qdrant and HNSW in the displayed results.
Postgres can keep embeddings with application data and enforce filtering in the database
Copplestone uses an image application to explain why Postgres features matter. Users upload photos of trash, which are converted to embeddings and stored for analysis. Unsafe images create storage, indexing, and access problems. His proof of concept uses partitions. A function compares each uploaded embedding with a canonical image, then assigns it to a good-cats or bad-cats partition based on a similarity threshold of 0.8. A Postgres trigger runs the function before each insert. The good partition can receive an index, while the bad partition can later be dropped and recreated without disturbing the good data.
Partitions provide a database-native way to isolate and remove unwanted embeddings
The partitioning example uses a similarity column as the range key. One partition stores values from 0.8 to 1, and a default partition receives everything else. Copplestone says the solution takes about 13 or 14 lines of Postgres code. Each partition has the properties of a regular table, so the application can index only the data it intends to search. On disk, Postgres groups the partitioned data together. This keeps the useful images fast to query and makes cleanup simple: the unwanted partition can be dropped and recreated when necessary.
Postgres features reduce application complexity around retrieval and access control
Copplestone's broader argument is that Postgres has decades of engineering and many primitives useful in AI applications. pgvector itself is an extension, so Supabase could add it by finding an existing community project and merging it into the platform. For retrieval-augmented generation, he points to row-level security, which lets developers write declarative rules on tables and keep user data separated. He also points out that storing embeddings beside operational data allows a single database fetch instead of multiple round trips. These features may not appear in isolated vector benchmarks, but they affect how much application code is needed.
Supabase is extending its vector offering toward billions of embeddings
Copplestone says Supabase is focusing on larger enterprise workloads, especially the problem of storing billions of vectors. The team is working on sharding with Citus, another Postgres extension, to split data across multiple nodes. He says the transaction scale they have observed grows linearly as nodes are added. He invites teams already storing billions of embeddings to become design partners. He also expects specialized vector databases to remain useful for capabilities that Postgres does not provide, including possibilities involving models placed closer to the database. For the basic use case of storing, indexing, and retrieving embeddings, he expects Postgres to keep moving in that direction.
"If you store your embeddings next to your operational data then you do a single fetch to your database."13:51
Who should watch
You are deciding whether embeddings should live in Postgres or in a dedicated vector database, and you want to hear the tradeoffs from a platform maintainer.
Your RAG system needs row-level security, database triggers, or filtering that has to happen close to application data.
You are planning for very large embedding collections and want to understand Supabase's direction on sharding with Citus.
