Héberger Weaviate sur un VPS

Weaviate ne se contente pas de stocker des vecteurs. Chaque objet porte ses propriétés (texte, nombres, dates, références) et un ou plusieurs vecteurs, si bien qu'une seule requête renvoie les documents pertinents avec toutes leurs métadonnées. Les modules text2vec-* calculent les embeddings à l'import, les modules generative-* transmettent les résultats à un LLM, et les modules de reranking réordonnent les candidats. Le tout s'interroge en REST, en GraphQL ou en gRPC. L'auto-héberger sur un VPS vous laisse choisir les modules activés, brancher vos propres modèles d'embeddings (par exemple via Ollama sur la même machine) et garder documents et vecteurs sur un serveur que vous administrez. Pour un assistant documentaire interne, un moteur de recherche de catalogue ou une mémoire d'agent, vous maîtrisez la latence, la rétention, le schéma des collections et la fréquence des sauvegardes. Et vous faites évoluer les ressources du VPS au rythme de votre corpus, plutôt qu'au rythme d'une grille de facturation au volume.

Pour tester avec quelques milliers d'objets, 2 Go de RAM suffisent. Pour un usage réel avec vectorisation déléguée à une API ou à Ollama, 4 Go et 2 vCPU constituent un point de départ confortable. Si vous faites tourner text2vec-transformers sur la même machine, prévoyez 8 Go ou plus : l'inférence sur CPU est lente à l'import massif. Côté disque, comptez de 30 à 60 Go de SSD selon le volume, en gardant de la marge car Weaviate passe en lecture seule quand l'occupation du disque dépasse un seuil (DISK_USE_READONLY_PERCENTAGE, 90 % par défaut). Trois ports comptent : 8080 pour REST et GraphQL, 50051 pour gRPC (utilisé par le client Python v4 pour les requêtes et les imports), et 2112 pour les métriques Prometheus si vous les activez. Aucun d'eux ne doit être exposé brut sur Internet : seul un reverse proxy en HTTPS, sur un sous-domaine comme vectors.mondomaine.com, doit faire face au public. Il vous faut enfin Docker et Docker Compose, déjà présents sur les VPS issus du Marketplace.

Dans Weaviate, les données vivent dans des collections (appelées classes dans l'ancienne API). Une collection définit ses propriétés typées (text, int, number, date, boolean, références vers d'autres collections), son vectorizer et la configuration de son index. Déclarez explicitement les propriétés plutôt que de laisser l'auto-schéma les deviner à la première insertion : un champ date deviné comme texte ne se filtre plus correctement. Pour un SaaS, activez la multi-tenancy à la création avec multi_tenancy_config=Configure.multi_tenancy(enabled=True) : chaque tenant reçoit son propre shard, s'interroge via collection.with_tenant("client-a"), et un tenant inactif peut être désactivé pour libérer la mémoire. Les named vectors permettent enfin d'attacher plusieurs vecteurs à un même objet, par exemple un pour le titre et un pour le contenu, chacun avec son modèle et son index. Attention : le vectorizer et le type d'index d'une collection ne se changent pas après coup, un changement passe par une nouvelle collection et une réimportation.

Par défaut, chaque collection utilise un index HNSW, rapide mais gardé en mémoire. La documentation de Weaviate donne une règle empirique : prévoir environ deux fois la taille brute des vecteurs. Un million de vecteurs de 768 dimensions en float32 pèsent environ 3 Go, soit autour de 6 Go de RAM pour l'index. L'index flat ne garde rien en mémoire et convient aux petites collections, notamment aux tenants d'un SaaS. L'index dynamic démarre en flat puis bascule en HNSW au-delà d'un seuil d'objets ; il nécessite ASYNC_INDEXING=true. Pour réduire l'empreinte, activez une quantization : PQ (product quantization) compresse fortement après une phase d'entraînement sur vos données, BQ (binary quantization) réduit chaque dimension à un bit et convient surtout aux vecteurs de grande dimension, SQ (scalar quantization) passe chaque dimension sur un octet. Fixez aussi GOMEMLIMIT à environ 80 % de la RAM allouée au conteneur pour que le ramasse-miettes de Go intervienne avant que le noyau ne tue le processus.

Ajoutez ENABLE_MODULES=backup-filesystem et BACKUP_FILESYSTEM_PATH=/var/lib/weaviate/backups, puis déclenchez une sauvegarde avec curl -X POST -H "Authorization: Bearer $CLE" -H "Content-Type: application/json" -d '{"id":"nightly-20261001"}' localhost:8080/v1/backups/filesystem. Le statut se lit sur GET /v1/backups/filesystem/nightly-20261001 et la restauration passe par POST /v1/backups/filesystem/nightly-20261001/restore. Une sauvegarde sur le même disque ne protège pas d'une perte du VPS : copiez le dossier ailleurs, ou utilisez backup-s3 avec BACKUP_S3_BUCKET vers un stockage objet compatible S3. Pour mettre à jour, lisez les notes de migration de la version visée, sauvegardez, changez le tag de l'image puis lancez docker compose pull && docker compose up -d. Passez les versions mineures une par une et ne redescendez jamais de version sur les mêmes données sans restaurer une sauvegarde.

Activez PROMETHEUS_MONITORING_ENABLED=true : Weaviate expose alors ses métriques sur le port 2112 (/metrics), à collecter par Prometheus et à afficher dans Grafana. Surveillez en priorité la mémoire du processus, la durée des imports par lot et le nombre d'objets par collection. Les endpoints /v1/.well-known/live et /v1/.well-known/ready servent de sondes à un healthcheck Docker ou à un outil comme Uptime Kuma. Côté système, docker stats donne la consommation instantanée du conteneur et df -h l'occupation du volume, à suivre de près puisque le passage en lecture seule est déclenché par le disque et non par la RAM. Gardez enfin les journaux avec docker compose logs -f weaviate : les erreurs de module et les échecs de vectorisation y apparaissent avec le nom de l'objet concerné.

Weaviate se justifie quand vous voulez que la base prenne en charge la vectorisation, la recherche hybride et la génération, plutôt que de les assembler vous-même dans le code applicatif. Il convient bien à un assistant documentaire, à une recherche de catalogue multilingue ou à un SaaS qui isole chaque client par tenant. Si vous calculez déjà vos embeddings et cherchez l'empreinte la plus faible, Qdrant est plus frugal. Si vos données sont déjà dans PostgreSQL et que le volume reste modeste, pgvector évite une brique de plus. Milvus vise les très gros volumes distribués, au prix d'une infrastructure plus lourde. Sur un VPS, commencez avec un seul nœud, un index HNSW, une clé API et des sauvegardes quotidiennes, puis ajoutez quantization et multi-tenancy quand les mesures le demandent. Pour aller plus loin, consultez nos guides sur Qdrant, Ollama et Open WebUI, qui complètent Weaviate dans une stack RAG auto-hébergée.