Pre-flight
Problem or motivation
Storing reduced precision vectors saves storage space and may increase RAG performance. It is part of the most-common RAG backends and should be supported by our wrapper.
Proposed solution
pgvector already supports halfvec storage type mentioned here for HNSW indices:
Supported types are:
vector - up to 2,000 dimensionshalfvec - up to 4,000 dimensions
...
The user then decides during configuration what storage format is expected (with checks whether the VSS backend provides this storage backend). This requires close coupling with oa-configurator during setup and configuration.
Internally, we just need to funnel the integration through and provide a proper framework for including this new capability.
Alternatives considered
None. This is standard practice to support various storage formats, especially since the supported backends partially already support this. Further backend extension, e.g. with DuckDB (#34) would directly benefit from an extensible capabilities framework.
Pre-flight
Problem or motivation
Storing reduced precision vectors saves storage space and may increase RAG performance. It is part of the most-common RAG backends and should be supported by our wrapper.
Proposed solution
pgvectoralready supportshalfvecstorage type mentioned here for HNSW indices:The user then decides during configuration what storage format is expected (with checks whether the VSS backend provides this storage backend). This requires close coupling with
oa-configuratorduring setup and configuration.Internally, we just need to funnel the integration through and provide a proper framework for including this new capability.
Alternatives considered
None. This is standard practice to support various storage formats, especially since the supported backends partially already support this. Further backend extension, e.g. with
DuckDB(#34) would directly benefit from an extensible capabilities framework.