Skip to main content
Chaque application Replit fonctionne avec deux bases de données. La base de données de développement est l’endroit où vous et Agent expérimentez pendant la construction. La base de données de production stocke les données en direct qui alimentent votre application publiée, gardant vos données réelles en sécurité pendant que vous continuez à construire.
Interface de gestion de la base de données de production

Comparaison

Agent ne peut pas modifier la base de données de production. Cette restriction existe pour garder votre base de données de production en sécurité.Agent peut apporter des modifications à votre base de données de développement. Au moment de la publication, tous les changements que vous avez effectués avec Agent sur la structure de votre base de données de développement (ajout et suppression de colonnes ou de tables) sont appliqués à votre base de données de production.Vous pouvez modifier manuellement vos données de production à tout moment : ouvrez l’outil Database, sélectionnez la base de données de production, ouvrez My Data, puis activez Edit.

Créer une base de données de production lors de la publication

Votre application publiée obtient sa propre base de données de production, distincte de la base de données de développement que vous utilisez pendant la construction.
  • Infrastructure actuelle (Helium) : Replit crée la base de données de production pour vous en cas de besoin lors de la publication. Il n’y a rien à configurer.
  • Bases de données de développement Neon legacy : Vous créez la base de données de production depuis les paramètres de publication. Ouvrez Production database settings pendant la publication, activez Create production database, et activez éventuellement Set up your production database with your current development data pour copier vos données de développement.
Paramètres de publication montrant les options de création de base de données de production

Paramètres de la base de données de production dans Publishing

Ne copiez des données de développement vers la production que si ces données peuvent être utilisées sans risque dans votre application en direct. Les données de développement peuvent inclure des comptes de test, des enregistrements d’exemple ou du contenu incomplet.
Après la publication, votre application publiée utilise la base de données de production tandis que l’éditeur de projet continue d’utiliser la base de données de développement, afin que les futurs changements de développement ne modifient pas directement les données en direct.

Apporter des modifications sûres à votre base de données de production

Lorsque vous publiez des mises à jour incluant des changements de base de données, certains changements nécessitent une planification minutieuse pour éviter les interruptions de service ou la perte de données.
Vous pourriez constater une brève interruption de votre application publiée pendant la publication. Les changements de base de données nécessitent parfois d’arrêter temporairement votre application pour éviter les conflits et protéger vos données pendant l’application des changements.
Les types de changements suivants nécessitent généralement de la prudence :
  • Supprimer des colonnes de base de données que le code de votre application référence encore
  • Changer les types de données des colonnes de façons que le code existant ne peut pas gérer
  • Ajouter des champs obligatoires sans valeurs par défaut à des tables existantes
  • Renommer des tables ou des colonnes qui cassent des requêtes existantes
  • Modifier des contraintes qui pourraient rejeter la logique applicative existante

Tester les changements avec un aperçu de déploiement

Un aperçu de déploiement est une copie temporaire et isolée de votre environnement de production où vous pouvez tester les changements de base de données et les mises à jour d’application avant qu’ils n’affectent les utilisateurs réels. Utilisez-le pour :
  • Vérifier que votre application fonctionne toujours avec les changements de base de données appliqués, sur l’ensemble de vos principaux parcours utilisateurs
  • Confirmer que les données existantes ont été correctement migrées et que les nouveaux champs contiennent les valeurs attendues
  • Surveiller les régressions de performance dans les temps de réponse des requêtes

Facturation et utilisation des ressources

Les bases de données de production sont facturées en fonction de l’utilisation via Neon, un fournisseur de bases de données serverless. La base de données entre dans un état inactif après cinq minutes d’inactivité, ce qui met en pause la facturation du temps de calcul, et se réactive instantanément dès qu’elle reçoit une requête. La vue d’accueil de l’outil Database affiche votre Billing Period et vos Hours of Compute Used. Pour le stockage par base de données, ouvrez l’onglet Settings de la base de données. Pour voir l’utilisation sur l’ensemble de vos applications Replit, ouvrez SettingsAccountAccount usage et développez les lignes PostgreSQL Storage et PostgreSQL Compute. Pour savoir comment Replit facture l’utilisation des bases de données, consultez Facturation des déploiements et des bases de données.

Supprimer une base de données de production

L’action de suppression est irréversible après une période de rétention de 7 jours. Assurez-vous de sauvegarder toute donnée importante avant de continuer. Les bases de données ont une période de suppression réversible de 7 jours pendant laquelle elles peuvent être restaurées ; contactez le support si vous avez besoin d’aide. Après 7 jours, la base de données est définitivement supprimée et irrécupérable.
Depuis l’outil Database :
  1. Sélectionnez la base de données, puis ouvrez l’onglet Settings
  2. Sélectionnez Remove database et confirmez en sélectionnant Yes, Remove database

Base de données de développement legacy

Avant le 4 décembre 2025, la base de données de développement était hébergée sur Neon. Toutes les nouvelles bases de données de développement sont hébergées sur l’infrastructure propre de Replit (Helium). Vous pouvez vérifier laquelle votre application utilise dans l’onglet Settings : un DATABASE_URL contenant neon.tech signifie l’infrastructure Neon legacy ; helium signifie l’infrastructure actuelle.

Mise à niveau de l’infrastructure de base de données

Replit met à niveau les bases de données de développement de Neon vers Helium, l’infrastructure PostgreSQL gérée propre à Replit. La mise à niveau est automatique, s’exécute une fois par application lorsque vous l’ouvrez dans l’éditeur de projet, et préserve toutes vos données. Ce qui change :
  • Latence plus faible et plus de stockage : Votre base de données fonctionne sur l’infrastructure Replit à côté de votre application, et votre limite de stockage passe de 10 Go à 20 Go.
  • Même moteur de base de données : Helium utilise PostgreSQL 16, la même version que Neon. Vos requêtes, schémas et données fonctionnent de la même façon.
  • Mise à jour automatique de la connexion : DATABASE_URL est mis à jour pour pointer vers Helium. Votre ancienne chaîne de connexion Neon est enregistrée sous NEON_DATABASE_URL dans vos Secrets pour référence.
  • Suppression des variables PG individuelles : PGHOST, PGPORT, PGUSER et PGPASSWORD sont supprimées. Utilisez DATABASE_URL à la place.
Pendant la mise à niveau, vous verrez un écran de progression « Upgrading your database ». Cela peut prendre de quelques minutes à quelques heures pour les grandes bases de données ; vous pouvez fermer l’onglet et revenir plus tard. Si la mise à niveau rencontre un problème, elle est automatiquement ignorée et retentée la prochaine fois que vous ouvrez votre application. Une fois terminée, une boîte de dialogue de confirmation apparaît. Pour la plupart des créateurs, aucune action n’est nécessaire par la suite. Vérifiez les points suivants s’ils s’appliquent à vous :
  • Chaînes de connexion Neon codées en dur : Mettez à jour le code qui référence une chaîne de connexion neon.tech pour utiliser la variable d’environnement DATABASE_URL à la place.
  • Rôles PostgreSQL personnalisés : Les rôles et permissions migrent automatiquement, mais les mots de passe des rôles ne peuvent pas être copiés. Réinitialisez les mots de passe des rôles personnalisés sur la nouvelle base de données.

Erreurs de connexion SSL après la mise à niveau

Si vous voyez des erreurs telles que The server does not support SSL connections, votre code de connexion force une négociation SSL. Neon exigeait SSL ; Helium fonctionne localement à côté de votre application et ne l’utilise pas. Rendez le paramètre SSL conditionnel à l’environnement :
Si vous utilisez un ORM comme Drizzle, Prisma ou Sequelize, consultez sa documentation pour savoir comment configurer les paramètres SSL de façon conditionnelle. Le même principe s’applique : désactivez SSL pour la base de données de développement et activez-le pour la production.

Applications forkées ayant partagé une base de données

Sous l’ancien système Neon, forker une application copiait le DATABASE_URL de l’application d’origine, si bien que les deux applications et leurs versions publiées se connectaient à la même base de données. Les bases de données legacy partagées ont été fermées le 8 juin 2026. Si votre application publiée a cessé de fonctionner ou a perdu l’accès à ses données, consultez Corriger une application publiée utilisant une base de données partagée ou contactez le support.

Prochaines étapes