Retain Your Document Collections Data in a Self-Managed Vector Store
Deprecation notice: The Document Collections feature is being decommissioned on August 31, 2026. After that date, your collections will no longer be available through the IONOS CLOUD API.
This guide shows you how to export your existing Document Collections data, provision a PostgreSQL vector database on IONOS CLOUD, re-embed and import your documents, and update your application to query the new store. If you prefer to start fresh instead, see Retrieval Augmented Generation.
Re-embedding is free until August 31, 2026 using dedicated migration model aliases.
Before you begin
To follow this guide, you need:
Requirement
Details
API key
IONOS CLOUD AI Model Hub API key with access to Document Collections and the embeddings endpoint
Python
3.10 or later
Target database
IONOS CLOUD PostgreSQL cluster with the pgvector extension, provisioned in Step 2.
Python packages
requests, psycopg2-binary
Install the required packages:
pip install requests psycopg2-binaryWhat to know before you start
Embedding vectors are not exported. The Document Collections API returns only the original text content. Every document must be re-embedded during import. IONOS CLOUD provides dedicated migration model aliases for this purpose. Re-embedding is free during the announced migration window. For more information, see Step 3.
Two vector dimensions are in use. The three supported embedding models produce vectors of either 768 or 1024 dimensions. Check the
embedding.modelfield in your export (captured by the export script in Step 1) to determine which models your collections use.Model
Dimensions
BAAI/bge-m31024
BAAI/bge-large-en-v1.51024
sentence-transformers/paraphrase-multilingual-mpnet-base-v2768
Plain text only. Document Collections stores plain text (
text/plain). No file conversion is needed.
Step 1: Export your data
The following script exports all your collections and their document text to a local JSON file.
Run the script with your credentials:
The script writes a dc_export.json file to the current directory containing all your collections and document text.
Step 2: Provision a vector database
The recommended target is IONOS CLOUD PostgreSQL with the pgvector extension. It is production-ready and provides full ACID guarantees with cosine, L2, and inner-product similarity operators.
Create a PostgreSQL cluster
Create a PostgreSQL 17 cluster through the IONOS CLOUD API:
External access: IONOS CLOUD managed PostgreSQL clusters use private IPs only. To connect from networks external IONOS CLOUD, set up a Network Load Balancer that forwards a public port 5432 to the cluster's private IP address. For more information, see Enable External Access to a PostgreSQL Database.
Verify the connection after setup:
Create the schema
Connect with psql and create the required schema. Two tables are needed because the three supported embedding models produce vectors of two different sizes:
Step 3: Import and re-embed your data
Free migration model aliases
IONOS CLOUD provides dedicated model aliases that are not billed during the migration window. Use the alias that matches the original embedding model of each collection:
Original model
Migration alias
Dimensions
BAAI/bge-m3
bge-m3-migration
1024
BAAI/bge-large-en-v1.5
bge-large-en-v1.5-migration
1024
sentence-transformers/paraphrase-multilingual-mpnet-base-v2
paraphrase-multilingual-mpnet-base-v2-migration
768
Important: After the migration window closes, switch to the standard model IDs. The migration aliases will no longer be available.
Run the import script
The following script reads your dc_export.json file, re-embeds each document using the IONOS CLOUD embeddings API, and inserts the results into PostgreSQL. It handles both 768-dimensional and 1024-dimensional collections in a single pass.
Run the import with your database and API credentials:
Step 4: Query the new vector store
After the import completes, replace Document Collections query calls with direct similarity searches against the new PostgreSQL database. The following example shows the pattern:
To build a full RAG pipeline on top of the new vector store, see the Retrieval Augmented Generation guide.
Step 5: Remove deprecated API parameters
Remove the collectionId and collectionQuery parameters from any existing chat completion or inference calls that relied on the built-in Document Collections context injection. These parameters will be removed from the API when the feature is fully decommissioned.
Step 6: Confirm successful migration
Before decommissioning your Document Collections data, run the following checks:
Document count: Compare the row count in
documents_768anddocuments_1024against the document counts returned by the Document Collections API. The totals must match.Spot-check retrieval: Run a known query against both the old Document Collections endpoint and the new PostgreSQL store. Verify that the top results are the same or semantically equivalent.
Application smoke test: Run your application's test suite with the new database configured to confirm end-to-end behavior.
Result: Your Document Collections data is now in a self-managed PostgreSQL vector store. You can safely stop using the Document Collections API and decommission your collections before the end-of-life date.
Last updated
Was this helpful?