Self Checks
1. Is this request related to a challenge you're experiencing? Tell me about your story.
- Is your feature request related to a problem? Please describe.
Currently, Dify supports various excellent Vector Databases (like Milvus, Qdrant, pgvector). However, for enterprise-level RAG applications with massive document datasets, traditional in-memory or SSD-bound vector databases can become extremely expensive.
There is a growing need for a Serverless, Compute-Storage Decoupled vector database architecture. Users want to leverage Cloud Object Storage (COS/S3) directly for vector storage and retrieval to significantly reduce costs while handling large-scale embeddings, but there is currently no native support for such an object-storage-based VDB in Dify.
- Describe the solution you'd like
I propose adding support for Cos Vectors as a new built-in Vector Database provider in Dify.
Cos Vectors is a high-performance vector storage engine built directly on top of Object Storage (using concepts similar to S3 Block FileSystem and Iceberg-like manifest indexing) to achieve extreme cost-efficiency and high concurrency without relying on heavy external KV stores.
Expected Integration Path:
Backend Integration: Implement a CosVectors class inheriting from BaseVector in api/core/rag/datasource/vdb/cos_vectors.
Standard Methods: Implement the core lifecycle methods: create, add_texts, search_by_vector, delete, etc.
Configuration: Add required environment variables and configuration models for Object Storage credentials (e.g., Endpoint, Access Key, Secret Key, Bucket Name).
UI/Console: Add the Cos Vectors configuration form to the Dify console (Data Source > Vector Database settings).
-
Describe alternatives you've considered
An alternative is using existing supported databases like pgvector or Milvus, but they require provisioning and managing underlying compute/storage instances which do not align with the extreme cost-reduction and pure object-storage architecture that Cos Vectors provides.
-
Additional context
By integrating Cos Vectors, Dify can offer a highly cost-effective RAG storage solution for users managing billions of vector tokens, particularly those who are heavily invested in Cloud Object Storage ecosystems and prefer a decoupled architecture.
-
Are you willing to submit a PR?
[x] Yes, I am willing to submit a PR to implement this feature.
2. Additional context or comments
No response
3. Can you help us with this feature?
Self Checks
1. Is this request related to a challenge you're experiencing? Tell me about your story.
Currently, Dify supports various excellent Vector Databases (like Milvus, Qdrant, pgvector). However, for enterprise-level RAG applications with massive document datasets, traditional in-memory or SSD-bound vector databases can become extremely expensive.
There is a growing need for a Serverless, Compute-Storage Decoupled vector database architecture. Users want to leverage Cloud Object Storage (COS/S3) directly for vector storage and retrieval to significantly reduce costs while handling large-scale embeddings, but there is currently no native support for such an object-storage-based VDB in Dify.
I propose adding support for Cos Vectors as a new built-in Vector Database provider in Dify.
Cos Vectors is a high-performance vector storage engine built directly on top of Object Storage (using concepts similar to S3 Block FileSystem and Iceberg-like manifest indexing) to achieve extreme cost-efficiency and high concurrency without relying on heavy external KV stores.
Expected Integration Path:
Describe alternatives you've considered
An alternative is using existing supported databases like pgvector or Milvus, but they require provisioning and managing underlying compute/storage instances which do not align with the extreme cost-reduction and pure object-storage architecture that Cos Vectors provides.
Additional context
By integrating Cos Vectors, Dify can offer a highly cost-effective RAG storage solution for users managing billions of vector tokens, particularly those who are heavily invested in Cloud Object Storage ecosystems and prefer a decoupled architecture.
Are you willing to submit a PR?
[x] Yes, I am willing to submit a PR to implement this feature.
2. Additional context or comments
No response
3. Can you help us with this feature?