Dify vector database selection for knowledge bases

Dify vector database selection for knowledge bases starts with one default you may not keep

The vector store behind Dify knowledge bases is set through environment variables, and Weaviate is the default. Once documents are indexed, changing that choice is hard to reverse, so the decision belongs before the first upload, not after the first demo. The Community Docker Compose stack includes a Weaviate container, which makes the default the path of least resistance. Dify's environment variable reference also lists Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch as alternatives, so the option set is wider than the Compose file suggests. A team that accepts the default without checking has still made a choice, and it will carry that choice into production.

Switching stores later means re-indexing knowledge base content into the new store. Dify app exports, the YAML DSL files used to move apps between environments, include app configuration, workflow nodes, prompts and knowledge base connections, but they do not carry knowledge base content. The documents must be processed again, and retrieval must be verified against the new store before users rely on its answers. Plan the re-indexing window, confirm that the original source files are still available to reprocess, and name the person who signs off on retrieval quality after the move. Do not assume that an app export preserves the index or its embeddings.

Four factors make this harder than it looks. First, the embedding model produces vectors of a fixed dimension, so the store's index must match that dimension, and a change of embedding model can mean rebuilding the index. Confirm the output dimension of your chosen model with its provider before the index is created. Second, metadata filtering decides whether retrieval can be scoped by document attributes such as department or classification, and filter behavior differs between stores. Test the filters your access rules depend on, not only the queries in the demo. Third, someone owns each store. Backups, upgrades, patching, scaling and on-call duties for the bundled Weaviate container differ from those for a pgvector extension on a managed PostgreSQL instance or a separate OpenSearch cluster. Fourth, a working demo is not a production retrieval setup.

A working demo shows that the store answers a question, usually with a small set of documents on one machine. A production retrieval setup also needs a representative corpus, recorded retrieval settings, a test set of questions with expected sources, and a named monitoring owner. Ask your platform team or the store's vendor to confirm the capabilities you need, such as the filter operators, search modes and backup and restore procedure available in your Dify version, because the environment reference does not settle those questions. Before go-live, record which store, embedding model, vector dimension and filter scheme you chose and why. That record turns a later migration into a planned project and gives reviewers a clear trail of the decision.

Which Dify components depend on the vector store

Dify knowledge base retrieval runs through a small set of services, and only one of them holds embedding vectors. The cards below name each component, what it does or stores, and what to confirm before you choose and size a vector store.

API and worker services

The api service handles knowledge base requests and retrieval, while the worker service runs background jobs that split uploaded documents, create embeddings and write them to the vector store. Both services must connect to the selected store, so changing the vector store is a configuration change for both. Check which variables each service reads in the .env.example for your version and confirm that both point to the same store.

Vector store chosen in configuration

The vector store is the only component that holds embedding vectors. Dify defaults to Weaviate, and the Community Docker Compose stack starts a Weaviate container alongside PostgreSQL, Redis, Nginx and the code sandbox. The environment variable reference also lists Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch as options. Whether you run the container or connect to an external service, confirm the connection settings, the backup method and who operates the store.

Enterprise resources checklist

The Dify Enterprise resources checklist requires a Qdrant vector database, and its production example uses a three-node Qdrant cluster alongside six worker nodes with 8 CPUs and 32 GB of RAM each. This checklist sets a reference point for planning a clustered store in an Enterprise deployment. Ask Dify to confirm whether your edition and version match this checklist before you size your own cluster.

PostgreSQL metadata database

PostgreSQL stores knowledge base records, document metadata and application configuration. It does not hold the vectors, so the vector store can be replaced without moving these records. Vectors for existing documents must still be regenerated in a new store, so confirm how your Dify version handles reindexing. Check that backups cover PostgreSQL and the vector store as separate sets, and test a restore of each.

Object storage for uploaded files

Uploaded source files are kept in the configured file storage, which can be OpenDAL, S3-compatible storage, Azure Blob, Google Cloud Storage or another supported provider. Object storage is separate from the vector store, so a vector store change does not move these files. Confirm which provider your deployment uses, who owns its lifecycle and retention policies, and that backups include the bucket or volume.

SSRF proxy and code sandbox

The SSRF proxy routes outbound requests through a proxy that blocks internal and private IP ranges, and the code sandbox runs code nodes. Neither one reads from or writes to the vector store, so both sit outside the retrieval path for knowledge bases. Review their settings during hardening, because changes to outbound rules can affect model provider and external tool calls.

Weaviate, Qdrant, Milvus, pgvector, OpenSearch or Elasticsearch: which store fits

This table compares the default Weaviate store with Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch for Dify knowledge bases. Read each row for the fit, the extra components your team would run and the points to settle with the vendor or against your Dify version. The main takeaway is that the default is the lowest-effort starting point, and a switch should be justified by an existing platform or an Enterprise requirement.

Option	When it fits	Operational cost	Confirm before choosing
Weaviate (default)	Included in the Docker Compose stack, so a pilot needs no separate vector service.	Runs as a container beside Dify. Back up its data with the rest of the stack before each upgrade.	Sizing for your document volume and the Weaviate version bundled with your Dify release.
Qdrant	Teams following the Enterprise resources checklist, which names Qdrant in its production example.	A separate service to deploy, monitor and back up. The checklist's example uses a three-node cluster.	Whether your sizing matches the checklist example and the Qdrant license terms for your deployment.
Milvus	Teams that already operate Milvus for other workloads and want one vector platform.	Several components to run and upgrade, and a skill set the Dify operators may not yet hold.	Supported Milvus versions for your Dify release, plus its filtering and hybrid search behavior and license terms.
pgvector	Teams with an established PostgreSQL operating model who want vectors in the database Dify already uses.	Extension management and index tuning move to the database team. Vector load shares resources with metadata.	Extension version on your PostgreSQL build and retrieval behavior at your document volume.
OpenSearch	Organizations that keep search and logging on one OpenSearch platform.	Cluster sizing, index lifecycle and security settings run as a second platform for Dify.	Supported OpenSearch versions, hybrid search support and edition terms with the vendor.
Elasticsearch	Organizations already standardized on Elasticsearch for enterprise search.	Cluster operations, upgrade coordination and subscription tiers for the features you need.	Which features your subscription includes, supported Dify versions and how hybrid retrieval is handled.
Stay on the default for a pilot	Proof of concept with a limited document set, where the goal is to evaluate retrieval quality.	No extra store to size now, but plan the migration path in case the pilot moves forward.	Document volume, retrieval quality targets and whether changing stores requires re-indexing in your Dify version.

How to configure a non-default vector store in Dify step by step

This sequence takes a self-hosted Dify instance from the default Weaviate store to a chosen alternative, such as Qdrant, Milvus, pgvector, OpenSearch or Elasticsearch. Each step ends with a check, so the team can confirm the store is reachable and that knowledge base retrieval returns the expected chunks before production documents are loaded.

Fix the embedding model and record its dimension
Decide which embedding model the knowledge bases will use, then record its output dimension and the provider that serves it. The vector index is built for that dimension, so a later change of model usually means re-embedding every document in every knowledge base. Write the model name, dimension and provider into the project's configuration record before touching the stack. Confirm the dimension in the model provider's documentation for the exact model version you plan to use. The step is done when the record exists and the team has agreed who approves any future model change.
Choose the store and confirm the deployment model
Pick one store from the supported options, weighing your team's operating experience, the document volume you expect and whether you need a clustered deployment. Dify's default is Weaviate, and the Community Docker Compose stack includes it, so choosing an alternative means you own that store's lifecycle. Confirm whether the store will run as a single container, a managed service in your cloud account, or a cluster, and check that your Compose or Kubernetes platform can host it. Dify Enterprise's resources checklist lists Qdrant as its required vector database, so an Enterprise deployment follows a different path. The step closes when the choice and deployment model are written down with a named owner.
Add the store to the deployment
Add a service for the chosen store to the Docker Compose file, or to the Kubernetes manifests or Helm values, using the image and version named in the store's documentation. Give it a named volume or persistent volume claim sized for your expected document volume and index growth, and set CPU and memory limits that match your sizing exercise. Keep the store's ports off public networks and attach it to the same internal network as the api and worker services. Validate the file with a configuration check such as docker compose config, then start the new store service on its own and confirm its health check or startup log reports ready.
Set the vector store variables in .env
Open .env.example and the Dify environment variable reference for the version you deploy, then copy only the variables that select the store and point Dify at its endpoint and credentials. Use the exact names from that version, because variable names can change between releases. Confirm them against the release notes for your target version before editing the live .env file. Store credentials with restricted file permissions, and leave SECRET_KEY unchanged, since changing it after deployment logs out all users. The step closes when a diff of .env against .env.example shows only the intended vector store entries and a second reviewer has checked the variable names.
Restart services and confirm startup
Recreate the api, worker and plugin daemon services so they read the new environment, and confirm the store container is healthy before you proceed. Watch the api and worker logs during startup for connection or authentication errors to the vector store, and treat any repeated error as a stop condition. Load the web console and sign in as an administrator, because a failed store connection can stay hidden until a knowledge base is used. The step closes when the logs show the services started without vector store errors and the console responds normally.
Verify connectivity from api and worker containers
Open a shell in the api container and in the worker container, then test a network connection to the store's host and port using a tool the image provides, such as a TCP check or an HTTP request to the store's readiness endpoint. Run the same check from the worker, since indexing runs there and can fail even when the api succeeds. Ask the store's documentation for its readiness path and whether it requires authentication. The step closes when both containers reach the store with the configured credentials, and a deliberately wrong credential produces an explicit authentication error.
Create a test knowledge base
Create a knowledge base in a non-production workspace and upload a small set of documents whose content you already know, such as a few short files on clearly different topics that you can check by hand. Select the embedding model recorded in the first step, then let indexing finish before you test. Check that each document shows as indexed in the console and that the worker logs show no indexing errors. Confirm the stored chunk count with the store's own admin tooling and compare it with the number you expect for those documents. The step closes when every test document is indexed and the counts match.
Confirm retrieval returns the expected chunks
Run a set of test questions whose answers you know appear in specific documents, and record the chunks each query returns along with its score. Compare the top results with the source passages you expect, and change chunk size, top-k or score threshold settings only after you have a baseline. Repeat the same queries after any change to the store, the embedding model or the retrieval settings. The step closes when the expected passages appear in the results for every test question, and the baseline is saved with the configuration record for future migrations and upgrades.

What drives the effort of a vector store decision in Dify

This table lists the factors that change the work and cost of choosing and running a vector store behind Dify knowledge bases. Read each row as a driver: the first column names it, the middle column explains how it raises effort, and the last column suggests how to keep it contained. The main takeaway is that scope decisions made early, such as the number of knowledge bases and embedding models, usually matter more than the choice of store itself.

Driver	How it raises effort	How to keep it down
Number and size of knowledge bases	Each knowledge base needs its own indexing, retrieval testing and ownership, and larger collections increase index build time and memory needs.	Start with the two or three knowledge bases that carry the first use cases and add others after retrieval quality is measured.
Document volume and update frequency	Frequent uploads, re-indexing and deletions keep the vector store under write load and make sync failures harder to spot.	Pilot on a bounded document set and confirm re-indexing time with the vendor before committing to a schedule.
Embedding models and vector dimensions	Mixing models or dimensions in one store forces separate indexes, and changing the embedding model later means re-embedding every document.	Standardize on one embedding model and dimension for the first rollout and record that choice in the design document.
Metadata filtering needs	Filtering by department, date or classification may require store features that differ between Weaviate, Qdrant, pgvector and the other options.	List the filters users need, then confirm each one is supported by the chosen store before building the knowledge base schema.
Number of environments	Development, test and production each need their own store, data loads and retrieval checks, which multiplies setup and maintenance.	Use one repeatable deployment definition for every environment and load only a sanitized sample into non-production stores.
Bundled container or managed or clustered store	The default bundled Weaviate container is simpler to start, while a managed or clustered store adds sizing, networking, backup and upgrade work.	Keep the bundled store for a pilot, and confirm with the vendor how a clustered option is sized and supported before production.
Existing operator skills	A store the team already runs needs less training, monitoring and incident handling than a new product added to the estate.	Reuse a store the organization already operates when it supports the required features and the team already owns its backups.
Compliance evidence such as backup and access records	Assessors typically ask for backup restore results, access control lists and change logs for the vector store, which must be produced and retained.	Decide early who owns store backups and access reviews, and ask the implementation partner to document both in the handover.
Quote scope for the work	A quote that does not name the stores, environments and knowledge bases in scope can change substantially once the work starts.	Ask for a written quote listing each store option, each environment, the number of knowledge bases, the data load and the evidence deliverables.

How the vector store setup differs by deployment model

The Docker Compose deployment is the simplest path in the Dify self-hosting docs. The stack starts the api, worker, web, plugin daemon and supporting services, including PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. Weaviate is the default vector store, so the index runs on the same host as the rest of the application.

Storage placement: Confirm in the Compose file where Weaviate persists its data, and place that path on storage you can snapshot.
Backup responsibility: Your team owns backups of the database, file storage and vector data. Take a backup before every upgrade, as the Compose docs advise.
Upgrade path: Follow the upgrade guide for the target release on the GitHub Releases page, then compare your environment with .env.example for new variables.
Community limits: The Community edition is limited to a single workspace and does not provide high availability. A host outage takes knowledge base retrieval down with the rest of the stack.

Before you load knowledge base content, test a full restore of the host onto a second machine and time it.

How to test Dify knowledge base retrieval before users depend on it

Before any user relies on a Dify knowledge base, run a fixed test set against the chosen vector store and confirm that the answers match documents you already know. Build the set from a small group of documents whose correct answers are written down in advance. Include questions that should return a specific passage and questions that should return nothing useful, so you can see both recall and false matches. Keep the test set and its expected answers under version control so every later run compares like with like. Record the embedding model, chunking settings, retrieval mode and top-k value with each run. Retrieval results depend on these settings, so a result without them cannot be reproduced. Ask your Dify contact or your own engineers to confirm which of these settings your Dify version exposes in the knowledge base configuration.

Next, confirm that vectors are written to the store you selected and that the default Weaviate instance in the Compose stack is no longer receiving writes. After indexing the test documents, inspect the target store directly and check that the expected collections or indexes exist and contain entries for each uploaded document. Then watch the default store during a fresh ingestion run and confirm it shows no new writes. Run retrieval queries with and without metadata filters. Filtered queries should return only documents carrying the matching metadata, and unfiltered queries should return the known passages. If either behavior is off, compare the stored payload with the metadata you uploaded before changing retrieval settings, because the usual cause is a metadata field that was not indexed the way you expected.

Then test failure behavior on purpose. Stop the vector store container, or block network access from the Dify api and worker services to it, and send the same test queries. A safe outcome is an explicit error in the application or API logs, surfaced to the operator as a failed retrieval. The outcome you must rule out is a silent empty answer, where the model responds as if no documents matched and nobody notices. Next, restart the store and confirm that retrieval recovers without re-uploading documents. Also restart the full stack and confirm the indexed data persists. Repeat these restart and outage checks after any configuration change to the store. If a failure produces a silent empty answer, do not release the knowledge base to users until the error path is fixed or the application handles empty retrieval explicitly.

Finally, when you move a knowledge base to a different store, re-index it and rerun the full test set against the same embedding model and chunking settings used for the baseline. The results should match the earlier baseline. Differences in ranking, missing passages or new false matches point to a change in the ingestion path, the settings or the store configuration, and each needs a fix before go-live. Keep the baseline results together with the Dify version and settings so each later upgrade can be checked the same way. Dify upgrades follow the guide for the target version and recommend a backup before every upgrade, so take the backup first, then repeat this test after the upgrade completes.

Securing the vector store and its credentials in Dify

Each card covers one control on the path between Dify and its vector store, from where credentials live to how outbound requests leave the network. Together they decide who can read embeddings and retrieved text, and which services can reach the store at all. Check each item against your deployed configuration, since Compose defaults are only a starting point.

Keep store credentials out of plain files

Weaviate, Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch each have their own authentication model, and the Dify settings for your chosen store carry the connection details. Confirm which credential your store requires, then keep it in a secrets manager or a restricted environment file readable only by the operator account. Check that the value does not appear in shell history, container inspect output or logs. Plan a rotation procedure that updates the Dify configuration and restarts the api and worker services together.

Limit store access to api and worker

The api and worker services should be the only Dify components that open connections to the vector store during normal operation. Place the store on the internal network those services share, and keep it off networks that other containers can reach directly. Verify placement by testing from each container, expecting connections from api and worker to succeed and connections from other containers to fail. Repeat the check after any change to the Compose file or host firewall rules.

Keep store ports off public interfaces

Vector stores often expose HTTP or gRPC ports for administration and data access, and a default Compose file may publish them on the host. Review the port mappings for every store container and remove any published port the host does not need. Confirm from outside the network that the store cannot be reached, including its administration and metrics ports. Record the result, because a store left exposed during testing is easy to forget and hard to notice later.

Enable TLS where the store supports it

TLS between Dify and the vector store protects queries, embeddings and retrieved text in transit, but the options depend on the store and version you deploy. Confirm the TLS modes, certificate formats and client authentication settings your store offers, and whether the Dify connection accepts the certificate authority chain you issue. Where a store cannot use TLS on the internal network, document that exception with its reason and owner, and name the network isolation controls that compensate for it.

Handle SECRET_KEY as a long-lived secret

SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials stored by Dify. Generate a strong random value before the first start, store it with the other secrets, and include it in every configuration backup. Changing it after deployment logs out all users, so treat any change as a planned event with a tested restore path. Confirm the effect on stored OAuth credentials in the documentation for your Dify version before changing it, and do not alter it casually during upgrades.

Route external vector services through SSRF_PROXY

SSRF_PROXY routes Dify's outbound requests through a proxy that blocks internal and private IP ranges. A vector service hosted on a private address may therefore be unreachable by default, so the path to it must be set up on purpose. Test the route from the api and worker containers, document the proxy rule or allow setting you used, and confirm that it opens no broader internal ranges. Record the decision in the change log so a later proxy change does not silently break retrieval.

What to monitor, back up, upgrade and document after the store is in place

Monitoring after go-live should cover the vector store and the Dify services together, because a retrieval fault often appears first as a slow or empty answer inside an app. Track the health of the store you selected, its disk use, and how quickly its index grows as documents are added, then compare those trends with the api and worker logs from the Docker Compose stack. Index growth matters for planning because each large upload or knowledge base re-index adds disk and memory demand on the store host. Set an alert for free space on the volume that holds the store data and act before it is reached. Ask your store vendor which health endpoints, logs or metrics it exposes for the version you run, and confirm that your monitoring tool can read them. Alert thresholds should come from that vendor documentation and from your own load tests.

Back up the vector store and PostgreSQL together in one planned operation. PostgreSQL holds the metadata that tells Dify which documents, segments and knowledge bases exist, while the vector store holds the embeddings used for retrieval. If the two are restored from different points in time, a knowledge base can point to vectors that no longer exist, or hold vectors with no matching metadata, and the errors may only surface in answers. Schedule both backups in the same window, record the start and finish time of each, and keep the store backup configuration with the handover documents. Your restore test should bring both back into one environment and then run the retrieval test set against it. Confirm with your store vendor which backup method it supports for your version and where the backup files are written.

Take a fresh backup before every Dify upgrade, since the Docker Compose documentation recommends this for each upgrade. Open the upgrade guide for the exact target version on the Dify GitHub Releases page and follow its steps in order. After the upgrade, compare your .env file with the .env.example shipped for the new version, because new variables may need values and existing ones may have changed meaning. Record each variable name you add or change in a change log, with no secret values. Review the release notes for changes to the vector store settings and to sandbox, proxy or internal API authentication, since these affect how the store is reached from the api and worker services. Run the retrieval test set after each upgrade and compare the results with the last recorded run.

Dify minor releases have arrived roughly monthly. The GitHub releases page lists 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026. Plan a monthly review of that page, and for each version you intend to adopt, read its upgrade guide before booking a change window. Decide whether the release touches components your store depends on, such as the api, the worker or the plugin daemon. The 1.16.1 release notes describe agent sandbox network isolation through a Squid proxy, token-based API authentication between services and sandboxed Jinja2 template rendering. Any deployment that uses agents or custom templates should test these changes against the chosen store before they reach production.

The handover pack should let an engineer who did not build the store restore it, understand it and rebuild it. Start with the store choice and the reason for it, including the trade-offs your team accepted. Next, record the embedding model and its vector dimension, because one index can hold only one dimension. Then list the environment variable names used for the vector store and related services, without their secret values, and state where those values are kept. Add the retrieval test set and the results from the most recent run so future changes can be compared. Follow with the backup and restore steps for PostgreSQL and the store, then the re-indexing procedure, including who runs it, the order in which knowledge bases are processed, and how completion is confirmed.

How long a Dify vector store change takes and what it asks of your team

Can our team change the Dify vector store without a partner?

Yes, if you have the skills and time to run the change in-house. The work involves editing deployment configuration, provisioning the new store, re-indexing every knowledge base, and testing retrieval quality, so the team needs people who can operate Docker or Kubernetes, manage the vector database, and judge whether answers are still accurate. Most of the effort sits in planning and testing rather than in the configuration change itself. A partner is useful when those skills are thin, when the change must land on a fixed date, or when you want an independent test set. Confirm the exact steps for your Dify version in the upgrade and environment documentation before you commit to a plan.

What drives the cost and effort of a Dify vector store change?

The main drivers are the number and size of knowledge bases, the document formats involved, and how many apps depend on retrieval. Cost splits into labor (planning, configuration, re-indexing runs, retrieval testing, cutover and rollback rehearsal), infrastructure (the new store, its storage and any clustering) and embedding model usage if documents must be embedded again. Labor is mostly one-time. Infrastructure and model usage recur, so ask what they cost per month at your data volume. Effort rises when documents need cleaning, when several stores or workspaces are involved, or when no test set exists yet. A written scope should list each of these items separately so you can see which ones you control.

Can we keep Weaviate when we change Dify knowledge base storage?

Yes, Weaviate is the default vector store in Dify, so keeping it is the simplest path. The decision is whether Weaviate still meets your sizing, availability and retrieval needs, not whether Dify supports it. If you keep it, the change may reduce to resizing, backup and tuning retrieval settings, which is much less work than a migration. If you move to another store, you will re-index anyway, so compare that cost against the problems you are trying to solve. For Dify Enterprise, the published resources checklist names Qdrant as the vector database, so confirm with the vendor whether Weaviate is supported in your Enterprise deployment before you assume it.

What does re-indexing a Dify knowledge base involve?

Re-indexing means reading each source document again, splitting it into chunks, creating embeddings and writing the vectors into the new store. The original files, the chunking settings and the embedding model all determine the output, so changing any of them changes retrieval results. Plan for a test pass after each knowledge base is indexed, comparing answers against your test set. Keep the old store running until the new one passes, so you can roll back. Check whether your source files are still available outside Dify, because a rebuild needs them. Ask your team or partner to confirm the re-indexing steps and any limits for your Dify version before scheduling the cutover.

Does a Dify app export move knowledge base content to a new store?

No. A Dify app export does not move knowledge base content. Dify exports apps as YAML DSL files that include app configuration, workflow nodes, model parameters, prompts and the connections to knowledge bases. The export excludes third-party API keys, knowledge base content and usage logs. After importing an app into a new environment, its knowledge base connections still need documents loaded and indexed in the target store. Keep the source documents, the chunking settings and the embedding model name in your change record, because those are the inputs you will need to rebuild the content.

Who on our team must own the vector store, embedding model and test set?

Name one accountable owner for each of the three items before the work starts. The vector store owner handles provisioning, capacity, backups, access and upgrades of the database. The embedding model owner decides which model is used, tracks its version and cost, and approves any change, because a different model produces different vectors. The test set owner maintains the questions, expected answers and acceptance criteria that prove retrieval still works. A single person can hold more than one role in a small team, but each role needs a named individual and a backup. Without a test set owner, nobody can say whether the change succeeded.

What should a fixed-scope quote for a vector store change include?

A fixed-scope quote should name the store, the knowledge bases, the document volume and the acceptance tests. Ask for the work broken into planning, environment preparation, store provisioning, re-indexing, retrieval testing, cutover, rollback rehearsal and handover. Each item should state what the partner delivers, what your team provides (access, documents, owners, test questions, change windows) and what is excluded. Ask how the quote handles unexpected document formats, a failed test pass and a second round of re-indexing. Confirm which recurring costs, such as infrastructure, model usage and any support retainer, sit outside the fixed fee. DeployOpen provides a quote from a written scope, so the scope is the document to get right first.

How do we check that Dify retrieval still works after the change?

Compare the new store's answers with the old store's answers using a fixed test set before you switch users over. Each test question should have an expected source document or answer, and the check should record whether the right passage was retrieved, not only whether the final answer sounds plausible. Run the same questions against both stores, review the differences with the test set owner, and tune retrieval settings only where the evidence supports it. Keep the old store and its data until the new one has passed and you have a tested rollback path. Record the results, because auditors and internal reviewers will ask how you verified the change.

How DeployOpen scopes, builds and hands over a Dify vector store change

DeployOpen plans and implements self-hosted Dify inside your own infrastructure, including the vector store behind each knowledge base. We start from a written scope that records which store you need, why, and how existing knowledge base content will be re-indexed, then build, test and document the change before handover.

How we scope

Engagements are fixed-scope, with the vector store choice, affected knowledge bases and success checks agreed in writing before work starts.
The scope records the current store (Weaviate by default or another option), the target store and the reason for changing it.
We confirm sizing inputs such as document volume, chunk counts and query patterns, and list which retrieval settings will be reviewed.

How we build

We deploy or reconfigure the target store in your environment and set the vector store variables in the Dify configuration.
Knowledge bases are re-indexed from source documents, since Dify does not export knowledge base content in app DSL files.
We test retrieval quality against agreed sample queries and check that connections from the api and worker services work before cutover.

How we hand over

You receive written documentation of the store configuration, environment variables, indexing steps and retrieval settings used.
We record a rollback path, including retaining the previous store and a backup taken before the change, so the cutover can be reversed.
Handover includes a walkthrough with your platform and data owners so they can run re-indexing and checks without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Upgrades to new Dify versions are checked against the vector store configuration, since new .env variables may appear after an upgrade.
Confirm with us in the quote which support hours, response expectations and review cycles apply to your environment.

Dify vector database selection for knowledge bases