Cómo ver el SQL de las migraciones en Laravel con php artisan migrate --pretend

Video thumbnail

Al momento de querer ejecutar las migraciones, tenemos una opción muy útil: el comando --pretend. Este comando nos permite obtener el SQL que Laravel ejecutaría internamente en la base de datos. Es decir, no aplica directamente los cambios, sino que te muestra las sentencias SQL que se van a ejecutar.

Si trabajas con Laravel el tiempo suficiente, tarde o temprano te encuentras con esta situación: necesitas saber qué SQL exacto va a ejecutar una migración, pero no puedes permitirte correrla directamente. Ya sea porque estás en producción, en un staging compartido o simplemente porque quieres revisar bien los cambios antes de tocar la base de datos.

A mí me pasó justo eso. Tenía varias migraciones desincronizadas con la base de datos y ejecutar un migrate a ciegas no era una opción. Ahí es donde descubrí una de las opciones más útiles (y menos explotadas) de Artisan.

Por qué necesitar ver el SQL de una migración en Laravel

Laravel abstrae muy bien la base de datos, pero esa comodidad tiene un precio: muchas veces no ves el SQL real que se ejecuta por debajo.

Ver ese SQL es clave cuando:

  • Estás trabajando en entornos compartidos.
  • No tienes acceso a la terminal del servidor.
  • Necesitas validar cambios delicados (alter tables, índices, constraints).
  • Quieres ejecutar el SQL manualmente desde un gestor como phpMyAdmin o DBeaver.

En mi caso, el problema era doble: muchas migraciones acumuladas y cero margen de error. Necesitaba saber exactamente qué iba a pasar antes de que pasara.

El comando php artisan migrate --pretend explicado con ejemplo real

Por ejemplo, como puedes ver en pantalla, aparecen muchas migraciones. Esto se debe a que tengo una mala sincronización entre las migraciones y la base de datos, pero bueno… esa es otra historia.

$ php artisan migrate --pretend

Como puedes ver, Laravel nos escupe por consola todo el SQL. El único detalle es que:

  1. Algunas líneas tienen caracteres extraños (íconos raros).
  2. No añade los puntos y comas al final de cada sentencia.

Qué hace exactamente --pretend

  • Recorre todas las migraciones pendientes.
  • Traduce el Schema Builder a SQL real.
  • Imprime en consola las sentencias CREATE, ALTER, DROP, etc.
  • No aplica ningún cambio en la base de datos.

Entonces, hay que darle un pequeño formato para que quede más legible. Si quieres, le puedes pedir a ChatGPT que te lo formatee por ti. Pero más allá de eso, lo más importante es que ya tienes el SQL listo para ejecutar en tu base de datos.

Qué NO hace (y errores comunes)

Conviene dejar esto claro:

  • ❌ No ejecuta las migraciones.
  • ❌ No actualiza la tabla migrations.
  • ❌ No garantiza que el SQL esté “listo para producción” tal cual sale.

Y aquí entra la parte que casi nadie comenta.

¿Para qué sirve esto?

Te estarás preguntando: ¿para qué puede ser útil?

Como he comentado en otros videos, esto es especialmente valioso cuando estás trabajando en ambientes compartidos, como servidores de staging o producción.

En estos entornos:

  1. No siempre tienes acceso a la terminal.
  2. Por lo tanto, no puedes ejecutar php artisan migrate directamente.
  3. Pero sí puedes acceder al manejador de base de datos (por ejemplo, phpMyAdmin o DBeaver).

Entonces, si necesitas crear nuevas tablas o aplicar cambios, puedes copiar este SQL y ejecutarlo directamente.

Antes de conocer esta opción, lo que yo hacía era:

  1. Ir al manejador de estado de base de datos.
  2. Exportar la tabla recién creada.
  3. Tomar el SQL resultante.
  4. Luego ejecutarlo en producción.

Un proceso más engorroso, sobre todo si tenías que modificar tablas existentes.

Con --pretend, todo más fácil

Ahora, con esta opción de --pretend, todo se simplifica:

  1. Puedes ver directamente el SQL, incluso si la migración modifica columnas existentes o añade restricciones.
  2. Ya no dependes de exportar desde el manejador visual.
  3. Y puedes copiar/pegar fácilmente el SQL para ejecutarlo en otros entornos.

Problemas reales al usar --pretend (y cómo solucionarlos)

El comando funciona, pero no es perfecto.

SQL sin punto y coma

Uno de los primeros detalles que noté es que muchas sentencias salen sin ; al final. Si copias y pegas eso directamente en un gestor de base de datos, puede darte errores.

Solución:

Un formateo rápido (incluso pedirle a Gemini que lo limpie) y listo.

Caracteres extraños en consola

Dependiendo del sistema y la versión, algunas líneas aparecen con símbolos raros o caracteres de control. No es grave, pero sí molesto si quieres reutilizar el SQL.

En mi caso, bastó con:

  • Copiar el output
  • Limpiarlo en un editor
  • Ajustar el formato

Lo importante es que el contenido SQL está ahí.

Cómo formatear el SQL rápidamente

Opciones rápidas:

  • Editor de código + búsqueda/reemplazo
  • Herramientas online de SQL formatter
  • O directamente… pedírselo a ChatGPT

Más allá del formato, el valor real es que ya tienes el SQL exacto que Laravel ejecutaría.

Usar el SQL de migraciones en entornos sin acceso a terminal

Aquí es donde --pretend realmente brilla.

En muchos entornos de staging o producción:

  • No puedes usar php artisan.
  • Pero sí tienes acceso a la base de datos.

Eso significa que puedes:

  • Ejecutar migrate --pretend en local.
  • Copiar el SQL.
  • Ejecutarlo manualmente en:
  • phpMyAdmin
  • DBeaver
  • MySQL Workbench
  • El gestor que uses

Yo antes hacía algo mucho más engorroso: creaba la tabla en local, la exportaba desde el gestor y luego ejecutaba ese SQL en producción. Funcionaba… pero era lento y frágil, sobre todo al modificar tablas existentes.

Con --pretend, ese dolor desaparece.

Cómo lo hacía antes y por qué --pretend es mejor

Antes:

  • Crear o modificar tablas en local.
  • Exportar estructura.
  • Ajustar el SQL manualmente.
  • Ejecutar en producción.
  • Rezar para no olvidar nada.

Ahora:

  • Un solo comando.
  • SQL generado directamente por Laravel.
  • Incluye alters, índices y constraints.
  • Mucho menos margen de error.

En escenarios reales, la diferencia es enorme.

Alternativas para inspeccionar migraciones en Laravel

Aunque --pretend es mi opción favorita, no es la única.

Revisar archivos de migración

  • Entrar a database/migrations y leer los métodos up() y down() ayuda a entender la lógica, aunque no siempre es trivial traducir mentalmente eso a SQL, sobre todo en migraciones grandes.
  • DB::statement y SQL crudo

Para casos más avanzados (vistas, funciones, triggers), muchas veces acabas usando SQL puro:

DB::statement("CREATE VIEW mi_vista AS SELECT ...");

Aquí no hay misterio: el SQL es explícito. Pero justo por eso, --pretend sigue siendo clave cuando usas el Schema Builder.

Preguntas frecuentes sobre el SQL de migraciones en Laravel

  • ¿--pretend ejecuta algo en la base de datos?
    • No. Solo muestra el SQL.
  • ¿Puedo usar ese SQL directamente en producción?
    • Sí, pero revísalo y formátalo antes.
  • ¿Funciona para modificar tablas existentes?
    • Sí, y de hecho es uno de sus mayores beneficios.
  • ¿Por qué Laravel no pone los ;?
    • Porque el output está pensado para lectura, no como script final.

Conclusión

Si alguna vez necesitas ver, revisar o reutilizar el SQL de tus migraciones en Laravel, php artisan migrate --pretend es una herramienta imprescindible. No solo te ahorra tiempo, sino que te da control real en escenarios donde ejecutar migraciones directamente no es una opción.

Desde que empecé a usarlo, dejé atrás muchos procesos manuales innecesarios. No es perfecto, pero bien usado, es una de esas pequeñas joyas que te hacen trabajar mucho más tranquilo.

Descubre cómo ver el SQL que ejecutan las migraciones en Laravel sin correrlas. Perfecto para entornos sin acceso a terminal.

Acepto recibir anuncios de interes sobre este Blog.

Andrés Cruz

EN In english