El problema: las migraciones SQL siguen siendo el eslabón débil del DevOps
El código de la aplicación pasa por una pull request: diff claro, revisión obligatoria, CI en verde antes del merge. La migración SQL, en cambio, llega a menudo por mensaje o por archivo compartido, se ejecuta a mano en el servidor de producción y, si algo sale mal — rollback manual, en el mejor de los casos.
Bytebase cubre esa brecha. Impone un workflow explícito: el desarrollador envía la migración, un revisor ve el diff, se ejecutan las reglas de lint automáticas (índice ausente, cláusula WHERE faltante, incumplimiento de las convenciones de nomenclatura) y después la migración se aplica en el orden dev → preproducción → producción. Cada etapa queda con marca de tiempo y se puede consultar en un registro de auditoría inmutable.
Lo que Bytebase aporta a su stack
- Revisión SQL estructurada: más de 200 reglas integradas detectan los antipatrones habituales antes de que la migración llegue a producción
- Pipeline multientorno: dev → preproducción → producción con puertas de validación y rollback en cada etapa
- Acceso web sin credenciales directas: los desarrolladores consultan producción desde el editor SQL de Bytebase — las credenciales nunca salen del servidor
- Registro de auditoría completo: cada consulta, migración, aprobación y rechazo queda registrado con el nombre del autor y la marca de tiempo
- Integración GitOps: conecte GitHub o GitLab y Bytebase detecta los nuevos archivos de migración y abre una tarea de revisión desde la PR
- 20+ motores compatibles: PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse, SQL Server, Oracle, TiDB y otros
Arquitectura: un contenedor, cero dependencias externas
Bytebase se ejecuta como un único contenedor Docker con una instancia PostgreSQL integrada. Sin base de datos externa que aprovisionar, sin Redis, sin workers separados — solo un docker run y un puerto 8080. La versión 3.21.1 (agosto de 2026) pesa unos 120 MB de imagen comprimida y arranca en menos de 20 segundos con un solo gigabyte de RAM.
Después se conecta como cliente a sus servidores de bases de datos existentes (o nuevos) — no sustituye su PostgreSQL ni su MySQL, se conecta a ellos para orquestar los cambios. Su infraestructura de datos permanece intacta.
Desplegar Bytebase en ServOrbit en 15 minutos
Contratar un VPS y desplegar desde el Marketplace
En su área de cliente ServOrbit, elija el VPS Start — sus 4 GB superan con creces el gigabyte que Bytebase reclama, y dejan margen para un equipo, abra el Marketplace en la categoría Desarrollo y haga clic en Desplegar en la ficha de Bytebase. Docker se instala y el contenedor arranca automáticamente.
Crear la cuenta de administrador
Vaya a
https://su-dominio(si hay un dominio asociado) o abra un túnel SSH —ssh -L 8080:127.0.0.1:8080 root@<ip>— y luego abrahttp://localhost:8080. El asistente de primer arranque le invita a crear su cuenta de administrador: correo electrónico y contraseña.Añadir su primera instancia de base de datos
En la interfaz, haga clic en Instances → Añadir una instancia. Indique el tipo de motor (PostgreSQL, MySQL…), el host, el puerto y las credenciales. Bytebase prueba la conexión, descubre las bases de datos y los esquemas, y los muestra en el árbol.
Configurar los entornos
En Environments, defina sus entornos (Dev, Staging, Production) y asocie cada instancia a su entorno. Puede exigir una aprobación humana obligatoria para las migraciones en producción.
Enviar y aprobar una migración
Haga clic en New Issue → Database change. Escriba su SQL, seleccione las bases de datos de destino, añada un revisor y envíelo. El revisor recibe una notificación, ve el diff y los resultados del lint, y luego aprueba o pide una corrección. Bytebase aplica en el orden de los entornos y registra cada acción.
GitOps: lanzar las revisiones desde sus pull requests
Bytebase se conecta a su repositorio de GitHub o GitLab. Configure la ruta de migración (p. ej. db/migrations/) y el patrón de archivo (p. ej. V{{version}}__{{description}}.sql). En cada PR que añada un archivo en esa ruta, Bytebase abre automáticamente una tarea de revisión vinculada a la PR: el estado de la migración (pendiente, aprobada, aplicada) aparece directamente en la PR de GitHub.
Esta integración cierra el bucle DevOps: el código y la migración viajan juntos en la misma PR, los revisan las mismas personas y se despliegan de forma coordinada. Desaparecen las migraciones huérfanas o ejecutadas fuera de ciclo.
Bytebase frente a las alternativas
Desplace la tabla
| bytebase | liquibase | flyway | |
|---|---|---|---|
| Interfaz de revisión web | ✅ Integrada | ❌ Solo CLI | ❌ CLI / plugin |
| Lint SQL automático | ✅ 200+ reglas | ⚠️ Limitado | ❌ No |
| Acceso SQL web seguro | ✅ Sí | ❌ No | ❌ No |
| Registro de auditoría | ✅ Completo | ⚠️ Básico | ⚠️ Básico |
| Self-hosted, contenedor único | ✅ Sí | ✅ Sí (CLI) | ✅ Sí (CLI) |
Uso en equipo: acceso sin credenciales directas
Para los equipos, el editor SQL de Bytebase sustituye los accesos directos a producción. Usted concede a sus desarrolladores un acceso a Bytebase — sin darles las credenciales de la base de datos. Bytebase actúa como intermediario de todas las consultas, aplica las políticas de enmascaramiento en las columnas sensibles (correo electrónico, teléfono, número de tarjeta) y conserva un log de cada operación.
Ante un incidente, puede averiguar con precisión quién ejecutó qué consulta, a qué hora y sobre qué base de datos. Es un requisito previo para las certificaciones SOC 2, ISO 27001 o el RGPD.
Edición Community: gratuita y sin límite de usuarios
La Community Edition cubre la totalidad del workflow de gestión de cambios, el editor SQL, el registro de auditoría y las integraciones GitOps. Las funcionalidades Enterprise (SSO, RBAC granular, data masking avanzado, workflows de aprobación personalizados) están disponibles en el plan de pago. Para la mayoría de los equipos self-hosted, la Community Edition es suficiente.
