At Index, we’ve switched from ChromaDB to pgvector for vector search.This way, we eliminate one more dependency for ComposeDB users, and the performance is much better.
Besides that, we believe vector search should be a built-in feature of any graph database, including ComposeDB, rather than being achieved with a separate protocol like Index.
I’m not sure if we could enable this by adding a vector scalar and extending createIndex definitions. One small detail: vector indexes need to be created separately based on their lengths or different model versions.
We are super excited about this and would love to work on it. Curious about your feedback.
We actually discussed adding a pgvector feature in OrbisDB very recently! This is either something that could be added via a plugin if we slightly update the plugins capabilities or natively. The plugin feels like the best option since not every developers will need this.
It would be great if we could work on this together!
Just to add to what Baptiste said, we were thinking about the role of plugins in the actual table creation/data type definition. pgvector was one of the examples used.
The idea is to allow plugins to either add an isolated column with a separate data type or modify the original one (TBD). Models would then be able to provide data type “hints” for plugins to pick up.
Main reasoning behind using plugins is the vast and ever-growing PG ecosystem. This way support for other data types would be enabled as needed (ie. geography of PostGIS) and operators would be able to select the best extension for their use case. It would enable experimenting with up and coming extensions (ie. pg_embedding before it got merged to pgvector) or the use of alternatives (ie. pgvecto.rs).