Bases de données d'aperçu
Chaque aperçu d'API a une base Postgres éphémère avec migrations et données d'exemple, isolée de la production.
Quand un aperçu inclut votre API, EvonX lui donne sa propre base de données : une base Postgres neuve et éphémère créée pour cet aperçu, migrée vers le schéma actuel et remplie de données d'exemple. Rien de ce que vous faites dans un aperçu ne peut toucher les données de production.
Ce que vous obtenez, automatiquement
-
Une instance Postgres dédiée démarre avec l'aperçu : pas une base partagée, et jamais celle de production.
-
Les migrations tournent pour que le schéma corresponde au code prévisualisé. Si le changement que vous testez modifie le modèle de données, la base de l'aperçu en tient déjà compte.
-
Les données d'exemple se chargent : des enregistrements réalistes (clients, réparations, rendez-vous, selon le domaine de votre app) pour que les écrans s'affichent avec du contenu plutôt que vides.
Quand l'aperçu est nettoyé, sa base de données part avec lui.
Ce que cela veut dire en pratique
- Testez sans retenue. Supprimez des enregistrements, annulez des rendez-vous, cassez un parcours exprès : au pire, vous relancez l'aperçu pour avoir une copie neuve.
- Les données ne persistent pas d'un aperçu à l'autre. Chaque aperçu repart des migrations et des données d'exemple. Si un test a besoin d'enregistrements précis, ajoutez-les au début de la session, ou demandez à l'IA d'étendre les données d'exemple pour que chaque futur aperçu les contienne.
- Les changements de schéma sont éprouvés sans risque. Une discussion qui modifie le modèle de données prouve ses migrations en les faisant tourner ici d'abord, avant qu'elles touchent votre base de production gérée.
Voir aussi
- Base de données gérée : l'équivalent en production.
- Lire les logs d'aperçu : la phase de préparation de la base dans les logs de démarrage.
Dernière mise à jour: 4 septembre 2026