Le problème : les migrations SQL restent le maillon faible du DevOps
Le code applicatif passe par une pull request : diff clair, revue obligatoire, CI verte avant merge. La migration SQL, elle, arrive souvent par message ou par fichier partagé, est jouée à la main sur le serveur de production, et si quelque chose tourne mal — rollback manuel, dans le meilleur des cas.
Bytebase comble cet écart. Il impose un workflow explicite : le développeur soumet la migration, un relecteur voit le diff, les règles de lint automatiques s'exécutent (index manquant, clause WHERE absente, non-respect des conventions de nommage), puis la migration est appliquée dans l'ordre env → recette → production. Chaque étape est horodatée et consultable dans un journal d'audit immuable.
Ce que Bytebase apporte à votre stack
- Revue SQL structurée : plus de 200 règles intégrées détectent les anti-patterns courants avant que la migration n'atteigne la production
- Pipeline multi-environnements : dev → recette → prod avec portes de validation et rollback à chaque étape
- Accès web sans identifiants directs : les développeurs interrogent la production via l'éditeur SQL de Bytebase — les credentials ne quittent jamais le serveur
- Journal d'audit complet : chaque requête, migration, validation et refus est tracé avec le nom de l'auteur et l'horodatage
- Intégration GitOps : connectez GitHub ou GitLab, Bytebase détecte les nouveaux fichiers de migration et ouvre une tâche de revue depuis la PR
- 20+ moteurs supportés : PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse, SQL Server, Oracle, TiDB et d'autres
Architecture : un conteneur, zéro dépendance externe
Bytebase tourne comme un seul conteneur Docker avec une instance PostgreSQL embarquée. Pas de base de données externe à provisionner, pas de Redis, pas de workers séparés — juste un docker run et un port 8080. La version 3.21.1 (août 2026) pèse environ 120 Mo d'image compressée et démarre en moins de 20 secondes sur un VPS 1 Go.
Il se connecte ensuite à vos serveurs de base de données existants (ou nouveaux) en tant que client — il ne remplace pas votre PostgreSQL ou MySQL, il s'y connecte pour orchestrer les changements. Vous gardez votre infrastructure de données intacte.
Déployer Bytebase sur ServOrbit en 15 minutes
Commander un VPS et déployer depuis le Marketplace
Dans votre espace client ServOrbit, choisissez une offre 1 Go+ RAM (2 Go pour les équipes), ouvrez le Marketplace catégorie Développement et cliquez Déployer sur la fiche Bytebase. Docker est installé et le conteneur démarre automatiquement.
Créer le compte administrateur
Naviguez vers https://votre-domaine (si un domaine est attaché) ou ouvrez un tunnel SSH — ssh -L 8080:127.0.0.1:8080 root@<ip> — puis ouvrez http://localhost:8080. Le wizard de premier lancement vous invite à créer votre compte administrateur : e-mail et mot de passe.
Ajouter votre première instance de base de données
Dans l'interface, cliquez Instances → Ajouter une instance. Renseignez le type de moteur (PostgreSQL, MySQL…), l'hôte, le port et les identifiants. Bytebase teste la connexion, découvre les bases et les schémas, et les affiche dans l'arborescence.
Configurer les environnements
Dans Environments, définissez vos environnements (Dev, Staging, Production) et associez chaque instance à son environnement. Vous pouvez imposer une approbation humaine obligatoire pour les migrations en production.
Soumettre et valider une migration
Cliquez New Issue → Database change. Rédigez votre SQL, sélectionnez les bases cibles, ajoutez un relecteur et soumettez. Le relecteur reçoit une notification, voit le diff et les résultats du lint, puis approuve ou demande une correction. Bytebase applique dans l'ordre des environnements et trace chaque action.
GitOps : déclencher les revues depuis vos pull requests
Bytebase se connecte à votre dépôt GitHub ou GitLab. Configurez le chemin de migration (ex. db/migrations/) et le pattern de fichier (ex. V{{version}}__{{description}}.sql). À chaque PR qui ajoute un fichier dans ce chemin, Bytebase ouvre automatiquement une tâche de revue liée à la PR : le statut de la migration (en attente, approuvée, appliquée) apparaît directement dans la PR GitHub.
Cette intégration ferme la boucle DevOps : le code et la migration voyagent ensemble dans la même PR, sont révisés par les mêmes personnes, et déployés de façon coordonnée. Les migrations restées orphelines ou jouées hors cycle disparaissent.
Bytebase vs les alternatives
| bytebase | liquibase | flyway | |
|---|---|---|---|
| Interface de revue web | ✅ Intégrée | ❌ CLI uniquement | ❌ CLI / plugin |
| Lint SQL automatique | ✅ 200+ règles | ⚠️ Limité | ❌ Non |
| Accès SQL web sécurisé | ✅ Oui | ❌ Non | ❌ Non |
| Journal d'audit | ✅ Complet | ⚠️ Basique | ⚠️ Basique |
| Self-hosted, conteneur unique | ✅ Oui | ✅ Oui (CLI) | ✅ Oui (CLI) |
Utilisation en équipe : accès sans identifiants directs
Pour les équipes, l'éditeur SQL de Bytebase remplace les accès directs à la production. Vous accordez à vos développeurs un accès à Bytebase — sans leur donner les credentials de la base. Bytebase mandataire toutes les requêtes, applique les politiques de masquage sur les colonnes sensibles (email, téléphone, numéro de carte), et conserve un log de chaque opération.
En cas d'incident, vous pouvez retrouver précisément qui a exécuté quelle requête, à quelle heure, sur quelle base. C'est un prérequis pour les certifications SOC 2, ISO 27001 ou RGPD.
Formule Community : gratuite et sans limite d'utilisateurs
La Community Edition couvre l'intégralité du workflow de gestion des changements, l'éditeur SQL, le journal d'audit et les intégrations GitOps. Les fonctionnalités Enterprise (SSO, RBAC fin, data masking avancé, workflows d'approbation personnalisés) sont disponibles dans la formule payante. Pour la majorité des équipes self-hosted, la Community Edition suffit.
