Adios
FR
Services de données · offres à partir de $10/mois

Déployer pgvector.Conservez les vecteurs avec les données relationnelles persistantes.

Démarrez PostgreSQL avec l’extension pgvector, connectez une application utilisant des embeddings, vérifiez les écritures vectorielles et les recherches de plus proches voisins, puis testez la persistance.

Déployer mon projetDéployer un modèle
Conserver le dépôtExaminer la compilation et les journauxDomaines personnalisés et TLS
Déploiement Adios

Version candidate

pgvector

Opérationnel

SOURCE

Git

REGION

de

ROUTE

HTTPS

01Source reçue

02Compilation terminée

03Environnement d’exécution démarré

04Vérification de santé réussie

Route promue en production

production.adios.run

Une mise en production adaptée à

pgvectorPostgreSQL 16EmbeddingsRecherche vectoriellePersistance

Le parcours de mise en production

Même opérationnel, un projet pgvector doit être mis en production en toute sécurité.

L’application ou le service ne représente qu’une partie de la production. Les résultats de compilation, l’état d’exécution, les contrôles de santé, les secrets, les journaux, les routes et la version promue doivent pouvoir être examinés ensemble.

Démarrer pgvector à partir d'un modèle versionné

Utilisez le modèle PostgreSQL 16 pgvector et créez la base applicative, les identifiants, l’extension, les tables et les index nécessaires à la recherche.

Faire de la persistance une décision explicite

Les vecteurs, les enregistrements sources et les index sont conservés sur un stockage PostgreSQL persistant. Définissez les besoins de sauvegarde, de restauration, de recalcul des embeddings et de reconstruction des index avant le lancement.

Garder l'état de service visible pour les opérateurs

Mesurez l’ingestion et les requêtes avec des dimensions et des nombres de lignes représentatifs, puis examinez ensemble les échecs de l’application et de la base de données.

Du code source à la mise en production

Trois étapes vous permettent de vérifier le parcours de déploiement.

Utilisez le code source et le fonctionnement en production déjà définis pour le projet. Le manifeste décrit ce que la plateforme doit compiler ou provisionner et les critères à remplir pour que le résultat soit prêt.

  1. 01

    Commencer par la source ou un modèle

    Importez le dépôt existant, ou examinez et déployez l’une des variantes de modèles précisément référencées ci-dessous.

    $adios login
  2. 02

    Revoir le contrat de déploiement

    Consignez dans adios.yaml les commandes, la version de l’environnement d’exécution ou du service, les critères de santé et les références aux secrets.

    $git diff -- adios.yaml
  3. 03

    Déployer et inspecter le résultat

    Suivez les résultats de compilation et d’exécution, vérifiez la version candidate, puis ouvrez la route ou la connexion de service promue en production.

    $adios up
adios.yaml
Votre projet
name: vector-db
template: pgvector:16

env:
  POSTGRES_USER: app
  POSTGRES_PASSWORD: secret://POSTGRES_PASSWORD
  POSTGRES_DB: search
Une fois le service disponible, créez l’extension vectorielle et le schéma applicatif au moyen d’une migration préalablement examinée.

Points de départ déployables

Démarrer pgvector à partir d'un modèle lorsque le dépôt n'est pas prêt.

Déployez la variante exacte PostgreSQL 16 pgvector, puis connectez-la à une application FastAPI, Node.js ou à une autre application utilisant des embeddings.

Services de données

pgvector 16

Modèles PostgreSQL 15, 16 et 17, ainsi que PostgreSQL 16 avec pgvector.

SQLGéré par Adios
Clé du modèle
pgvector:16
Environnement d’exécution
postgres
Dépôt
template-pgvector-16
Emplacement de la source
.
git clone https://github.com/adiosdotdev/template-pgvector-16.git
cd template-pgvector-16
adios up
DéployerAfficher la source
Créer l’exemple de recherche sémantique FastAPI

Avant production

Vérifier la charge de travail.Puis promouvez la version en production.

Pour sécuriser la première mise en production, partez d’une compilation ou d’une configuration de service reproductible et d’un aperçu qui sollicite les dépendances réellement utilisées en production.

Prêt quand...

  • Les dimensions des embeddings et les opérateurs de distance sont définis.
  • Les identifiants sont stockés dans des secrets.
  • Les migrations de schéma et d’index sont reproductibles.
  • Les sauvegardes incluent les données sources nécessaires à la restauration.

Prévisualiser quand...

  • Le type d’index ou la métrique de distance change.
  • Le changement de modèle d’embeddings modifie les dimensions des vecteurs.
  • L’ingestion massive de données mobilise les mêmes ressources que les requêtes de production.

Les réponses à vos questions

Ce qu’il faut savoir avant de déployer pgvector.

Vérifiez les limites de l’environnement d’exécution ou du service, le chemin du modèle, le comportement en cas d’échec et les contrôles de production avant de créer la première version.

Puis-je déployer pgvector à partir d’un modèle officiel ?

Oui. Choisissez le modèle pgvector correspondant à la version ou à la configuration souhaitée, stockez les identifiants dans des secrets Adios et déployez-le depuis la console ou avec adios up.

Le modèle pgvector utilise-t-il un stockage persistant ?

Les vecteurs, les enregistrements sources et les index sont conservés sur un stockage PostgreSQL persistant. Définissez les besoins de sauvegarde, de restauration, de recalcul des embeddings et de reconstruction des index avant le lancement.

Le modèle inclut-il PostgreSQL et pgvector ?

Oui. Le modèle pgvector:16 lance PostgreSQL 16 avec l’extension vector disponible. Votre application reste responsable du schéma, des migrations, de la génération des embeddings et de la conception des requêtes.

FastAPI peut-il se connecter au modèle pgvector ?

Oui. Injectez la chaîne de connexion PostgreSQL dans l’environnement d’exécution FastAPI et vérifiez l’ingestion, les requêtes vectorielles, les échecs de dépendances et la reconnexion.

Où stocker les mots de passe de la base de données et du broker ?

Stockez les valeurs sensibles dans les secrets Adios et référencez-les avec secret://NAME. Ne placez pas les identifiants de production directement dans adios.yaml et ne les enregistrez pas dans Git.

Que dois-je vérifier avant de recevoir du trafic de production ?

Vérifiez l’authentification, la connectivité applicative, les écritures et lectures, la persistance après redémarrage, les besoins de sauvegarde ou de restauration, la capacité et le comportement en cas d’échec de chaque application dépendante.

Autres options de déploiement

Connectez le reste de votre stack.

Parcourir toutes les pages de déploiement

Déployer PostgreSQL

Choisissez une version de PostgreSQL, conservez les identifiants de la base de données hors de Git, ajoutez un stockage persistant, connectez l’application et vérifiez les données après un redémarrage.

Déployer FastAPI

Déployez un service FastAPI en conservant avec son code source la cible d’import ASGI, l’installation des dépendances, le port d’exécution, l’endpoint de contrôle de santé, les secrets et la version promue.

Déployer Python

Exécutez une application web ou un worker Python en conservant le fichier de dépendances, la commande du processus, la route de contrôle de santé et la configuration alimentée par des secrets avec le code source.

Déployer Workflows Adios

Déployez des tâches planifiées, des traitements de webhooks, des étapes d’approbation, des tâches de maintenance et des automatisations opérationnelles à partir d’un manifeste de workflow versionné.

La première version

Déployer pgvector avec le code source et les éléments de vérification associés.

Partez du dépôt ou d’un modèle, vérifiez le contrat de déploiement et examinez la version qui sera promue en production.

Commencez par AdiosComparer les offres