Skip to main content
This guide explains how to migrate from Weaviate client v3 to v4.17.0 and upgrade your Weaviate server from version 1.19.0 to 1.27.0 or higher. This migration is required for Dify versions that include the weaviate-client v4 upgrade.

Overview

Starting with Dify v1.9.2, the weaviate-client has been upgraded from v3 to v4.17.0. This upgrade brings significant performance improvements and better stability, but requires Weaviate server version 1.27.0 or higher.
BREAKING CHANGE: The new weaviate-client v4 is NOT backward compatible with Weaviate server versions below 1.27.0. If you are running a self-hosted Weaviate instance on version 1.19.0 or older, you must upgrade your Weaviate server before upgrading Dify.

Who Is Affected?

This migration affects:
  • Self-hosted Dify users running their own Weaviate instances on versions below 1.27.0
  • Users currently on Weaviate server version 1.19.0-1.26.x
  • Users upgrading to Dify versions with weaviate-client v4
Not affected:
  • Cloud-hosted Weaviate users (Weaviate Cloud manages the server version)
  • Users already on Weaviate 1.27.0+ can upgrade Dify without additional steps
  • Users running Dify’s default Docker Compose setup (Weaviate version is updated automatically)

Breaking Changes

Client v4 Requirements

The weaviate-client v4 introduces several breaking changes:
  1. Minimum Server Version: Requires Weaviate server 1.27.0 or higher
  2. API Changes: New import structure (weaviate.classes instead of weaviate.client)
  3. gRPC Support: Uses gRPC by default on port 50051 for improved performance
  4. Authentication Changes: Updated authentication methods and configuration

Why Upgrade?

  • Performance: Significantly faster query and import operations via gRPC (50051)
  • Stability: Better connection handling and error recovery
  • Future Compatibility: Access to latest Weaviate features and ongoing support
  • Security: Weaviate 1.19.0 is over a year old and no longer receives security updates

Version Compatibility Matrix

Dify VersionWeaviate-client VersionCompatible Weaviate Server Versions
≤ 1.9.1v3.x1.19.0 - 1.26.x
≥ 1.9.2v4.17.01.27.0+ (tested up to 1.33.1)
This migration applies to any Dify version using weaviate-client v4.17.0 or higher.
Weaviate server version 1.19.0 was released over a year ago and is now outdated. Upgrading to 1.27.0+ provides access to numerous improvements in performance, stability, and features.

Prerequisites

Before starting the migration, complete these steps:
  1. Check Your Current Weaviate Version
    Look for the version field in the response.
  2. Backup Your Data
    • Create a complete backup of your Weaviate data
    • Backup your Docker volumes if using Docker Compose
    • Document your current configuration settings
  3. Review System Requirements
    • Ensure sufficient disk space for database migration
    • Verify network connectivity between Dify and Weaviate
    • Confirm gRPC port (50051) is accessible if using external Weaviate
  4. Plan Downtime
    • The migration will require service downtime
    • Notify users if running in production
    • Schedule migration during low-traffic periods

Migration Paths

Choose the migration path that matches your deployment setup and current Weaviate version.

Choose Your Path

  • Path A – Migration with Backup (from 1.19): Recommended if you are still on Weaviate 1.19. You will create a backup, upgrade to 1.27+, repair any orphaned data, and then migrate the schema.
  • Path B – Direct Recovery (already on 1.27+): Use this if you already upgraded to 1.27+ and your knowledge bases stopped working. This path focuses on repairing the data layout and running the schema migration.
Do not attempt to downgrade back to 1.19. The schema format is incompatible and will lead to data loss.

Path A: Migration with Backup (From 1.19)

Safest path. Creates a backup before upgrading so you can restore if anything goes wrong.

Prerequisites

Step A1: Enable the Backup Module on Weaviate 1.19

Edit docker/docker-compose.yaml so the weaviate service includes backup configuration:
Restart Weaviate to apply the change:

Step A2: Create a Backup

  1. List your collections:
  2. Trigger the backup: include specific collection names if you prefer.
  3. Check backup status:
  4. Verify backup files exist:

Step A3: Upgrade to Weaviate 1.27+

  1. Upgrade Dify to a version that ships Weaviate 1.27+:
  2. Confirm the new Weaviate image:
  3. Restart with the new version:

Step A4: Fix Orphaned LSM Data (if present)

You can fix orphaned LSM data either from the host or inside the container: Option A: From host (if volumes are mounted):
Option B: Inside Weaviate container (recommended):

Step A5: Migrate the Schema

  1. Install dependencies (in a temporary virtualenv is fine):
  2. Run the migration script either locally or inside the Worker container.
    Option A: Run locally (if you have Python 3.12 and dependencies installed):
    Option B: Run inside Worker container (recommended for Docker setups):
    The migration script uses environment variables for configuration, making it suitable for running inside Docker containers. For Dify 1.11.0+, if you encounter permission errors with uv, use uv run --no-cache instead.
  3. Restart Dify services:
  4. Verify in the UI: open Dify, test retrieval against your migrated knowledge bases.
    For large collections (over 10,000 objects), verify that the object count matches between old and new collections. The migration script will display verification counts automatically.
After confirming a healthy migration, you can delete weaviate_migration_env and the backup files to reclaim disk space.

Path B: Direct Recovery (Already on 1.27+)

Only use this path if you already upgraded to 1.27+ and your knowledge bases stopped working. You cannot create a 1.19 backup anymore, so you must repair the data in place.

Prerequisites

  • Currently running Weaviate 1.27+ (including 1.33)
  • Docker + Docker Compose installed
  • Python 3.12 for the migration script

Step B1: Repair Orphaned LSM Data

Stop Weaviate and fix orphaned LSM data:
Restart Weaviate:
List collections and confirm object counts are non-zero:

Step B2: Run the Schema Migration

Follow the same commands as Step A5. You can run the script locally or inside the Worker container: To run inside Worker container:
The migration script uses cursor-based pagination to safely handle large collections. Verify object counts match after migration completes.

Step B3: Verify in Dify

  • Open Dify’s Knowledge Base UI.
  • Use Retrieval Testing to confirm queries return results.
  • If errors persist, inspect docker compose logs weaviate for additional repair steps (see Troubleshooting).

Data Migration for Legacy Versions

CRITICAL: Data Migration RequiredYour existing knowledge bases will NOT work after upgrade without migration!Why Migration is Needed:
  • Old data: Created with Weaviate v3 client (simple schema)
  • New code: Requires Weaviate v4 format (extended schema)
  • Incompatible: Old data missing required properties
Migration Options:
  • Option A: Use Weaviate Backup/Restore
  • Option B: Re-index from Original Documents
  • Option C: Keep Old Weaviate (Don’t Upgrade Yet) If you can’t afford downtime or data loss.

Automatic Migration

In most cases, Weaviate 1.27.0 will automatically migrate data from 1.19.0:
  1. Stop Weaviate 1.19.0
  2. Start Weaviate 1.27.0 with the same data directory
  3. Weaviate will detect the old format and migrate automatically
  4. Monitor logs for migration progress and any errors

Manual Migration (If Automatic Fails)

If automatic migration fails, use Weaviate’s export/import tools:

1. Export Data from Old Version

Use the Cursor API or backup feature to export all data. For large datasets, use Weaviate’s backup API:

2. Import Data to New Version

After upgrading to Weaviate 1.27.0, restore the backup:
For comprehensive migration guidance, especially for complex schemas or large datasets, refer to the official Weaviate Migration Guide.

Configuration Changes

New Environment Variables

The following new environment variable is available in Dify versions with weaviate-client v4:

WEAVIATE_GRPC_ENDPOINT

Description: Specifies the gRPC endpoint for Weaviate connections. Using gRPC significantly improves performance for batch operations and queries. Format: hostname:port (NO protocol prefix) Default Ports:
  • Insecure: 50051
  • Secure (TLS): 443
Examples:
Do NOT include protocol prefixes like grpc:// or http:// in the WEAVIATE_GRPC_ENDPOINT value. Use only hostname:port.

Updated Environment Variables

All existing Weaviate environment variables remain the same:
  • WEAVIATE_ENDPOINT: HTTP endpoint for Weaviate (e.g., http://weaviate:8080)
  • WEAVIATE_API_KEY: API key for authentication (if enabled)
  • WEAVIATE_BATCH_SIZE: Batch size for imports (default: 100)
  • WEAVIATE_GRPC_ENABLED: Enable/disable gRPC (default: true in v4)

Complete Configuration Example

Verification Steps

After completing the migration, verify everything is working correctly:

1. Check Weaviate Connection

Verify Weaviate is accessible and running the correct version:

2. Verify Dify Connection

Check the Dify logs for successful Weaviate connection:
Look for messages indicating successful connection without “No module named ‘weaviate.classes’” errors.

3. Test Knowledge Base Creation

  1. Log into your Dify instance
  2. Navigate to Knowledge Base section
  3. Create a new knowledge base
  4. Upload a test document (PDF, TXT, or MD)
  5. Wait for indexing to complete
  6. Check that status changes from “QUEUING” → “INDEXING” → “AVAILABLE”
If documents get stuck in “QUEUING” status, check that the Celery worker is running: docker compose logs worker.
  1. Create or open a chat application with knowledge base integration
  2. Ask a question that should retrieve information from your knowledge base
  3. Verify that relevant results are returned with correct scores
  4. Check the citation/source links work correctly

5. Verify gRPC Performance

If gRPC is enabled, you should see improved performance:
With gRPC properly configured, vector search queries should be 2-5x faster compared to HTTP-only connections.

Troubleshooting

Issue: “No module named ‘weaviate.classes’”

Cause: The weaviate-client v4 is not installed, or v3 is still being used. Solution:

Issue: Connection Refused on gRPC Port (50051)

Cause: Port 50051 is not exposed, not accessible, or Weaviate is not listening on it. Solution:
  1. For Docker Compose users with bundled Weaviate: The port is available internally between containers. No action needed unless you’re connecting from outside Docker.
  2. For external Weaviate:
  3. Check firewall rules:

Issue: Authentication Errors (401 Unauthorized)

Cause: API key mismatch or authentication configuration issue. Solution:
  1. Verify API key matches in both Weaviate and Dify:
  2. If using anonymous access:
    Then remove WEAVIATE_API_KEY from Dify configuration.

Issue: Documents Stuck in “QUEUING” Status

Cause: Celery worker not running or not connected to Redis. Solution:

Issue: Slow Performance After Migration

Cause: gRPC not enabled or configured incorrectly. Solution:
  1. Verify gRPC configuration:
    Should show:
  2. Test gRPC connectivity:
  3. If still slow, check network latency between Dify and Weaviate

Issue: Schema Migration Errors

Cause: Incompatible schema changes between Weaviate versions or corrupted data. Solution:
  1. Check Weaviate logs for specific error messages:
  2. List current schema:
  3. If necessary, delete corrupted collections (⚠️ this deletes all data):
  4. Restart Dify to recreate schema:
Deleting collections removes all data. Only do this if you have a backup and are prepared to re-index all content.

Issue: Docker Volume Permission Errors

Cause: User ID mismatch in Docker containers. Solution:

Issue: Permission Denied When Running Migration Script (Dify 1.11.0+)

Cause: The /home/dify directory may not exist in newer Dify versions, causing uv cache creation to fail. Solution:

Rollback Plan

If the migration fails and you need to rollback:

Step 1: Stop Services

Step 2: Restore Backup

Step 3: Revert Dify Version

Step 4: Restart Services

Step 5: Verify Rollback

Check that services are running with old versions:
Always test the rollback procedure in a staging environment first if possible. Maintain multiple backup copies before attempting major migrations.

Additional Resources

Official Documentation

Community Resources

Migration Tools

Summary

This migration brings important improvements to Dify’s vector storage capabilities:
  • Better Performance: gRPC support dramatically improves query and import speeds (2-5x faster)
  • Improved Stability: Enhanced connection handling and error recovery
  • Security: Access to security updates and patches not available in Weaviate 1.19.0
  • Future-Proof: Access to latest Weaviate features and ongoing support
While this is a breaking change requiring server upgrade for users on old versions, the benefits significantly outweigh the migration effort. Most Docker Compose users can complete the migration in under 15 minutes with the automatic update.
If you encounter any issues not covered in this guide, please report them on the Dify GitHub Issues page with the label “weaviate” and “migration”.
Last modified on June 11, 2026