Seonglae ChoClient
Vector Database
For production, when using pgVector in an RDBMS rather than a vector database, simply adding an embedding column to an existing table is a bad practice. This is because if you finetune or change the model, you have to regenerate embeddings in all tables, which is very unstable and difficult to manage during migration. Therefore, it's better practice to have a separate embedding table that references the original id table like a junction table. While you can have separate tables per entity, sharing the same table doesn't pose a Polymorphic FK problem in this case. When the embedding version changes, you can simply populate new rows and migrations can flow continuously. Additionally, you can delete stale entries after migration, making it much more stable. This solution also doesn't require column expansion even when multiple embedding types are added per table, and embeddings from multiple tables can be shared like ReBAC, which is an advantage.
pgVector Usages
Performance
Pgvector Is Now Faster than Pinecone at 75% Less Cost
Introducing pgvectorscale, an open-source PostgreSQL extension that supercharges pgvector’s vector search performance for large-scale vector workloads.
https://www.timescale.com/blog/pgvector-is-now-as-fast-as-pinecone-at-75-less-cost/
Hosting
pgvector: Embeddings and vector similarity<!-- --> | Supabase Docs
pgvector: a PostgreSQL extension for storing embeddings and performing vector similarity search.
https://supabase.com/docs/guides/database/extensions/pgvector
