Postgres en un contenedor y un Makefile: dev local sin complicaciones
Una configuración minimalista con un solo contenedor de Postgres, migraciones SQL y un Makefile que resetea la base en segundos. Ideal para equipos que buscan rapidez y reproducibilidad.
Configuración mínima
Postgres para desarrollo local puede ser tan simple como un contenedor y un Makefile. En el archivo docker-compose.yml se expone solo el servicio db con la imagen postgres:17 y las variables de entorno POSTGRES_USER, POSTGRES_PASSWORD y POSTGRES_DB establecidas a app. Se monta el volumen pgdata en /var/lib/postgresql/data y se ejecuta el comando postgres -c fsync=off -c synchronous_commit=off -c full_page_writes=off para desactivar la durabilidad durante el desarrollo. Un healthcheck verifica que la base esté lista con pg_isready.
.env y migraciones
El único punto de configuración que la aplicación necesita es DATABASE_URL. Las migraciones son archivos SQL numerados (001_users.sql, 002_sessions.sql, etc.) que se aplican secuencialmente. No se usan ORM ni DSL, lo que facilita la lectura de la estructura.
Makefile
El Makefile contiene la regla db-reset que:
- Levanta el contenedor con
docker compose up -d --wait db. - Elimina y vuelve a crear la base de datos
app_dev. - Aplica todas las migraciones y el archivo
seed.sql. - Ofrece la regla
db-shellpara conectarse conpsql.
Esta operación tarda menos de un segundo, lo que evita que los desarrolladores eviten resetear la base.
Tests con bases de datos clonadas
Para pruebas unitarias, en lugar de truncar tablas, se clona la base app_template en una nueva base de prueba (CREATE DATABASE test_a1b2c3 TEMPLATE app_template). Clonar a nivel de archivo dura apenas milisegundos, garantizando bases de datos aisladas y completamente migradas. La única restricción es que no se puede conectar a la plantilla mientras se clona.
Cuándo funciona y cuándo no
Funciona cuando:
- Se usa Postgres estándar o extensiones con imagen publicada.
- Los datos seed son pequeños y se reconstruyen en segundos.
- Se ejecuta en una única base de datos.
Se vuelve incómodo cuando:
- Se necesitan extensiones que no vienen con la imagen base (por ejemplo,
pgvectoropostgis). - Se requiere rendimiento con grandes volúmenes; las migraciones deben probarse contra datos más extensos.
- El proveedor de hosting restringe superusers o ciertas extensiones.
- Se gestionan múltiples proyectos que compiten por el puerto 5432; se asignan puertos diferentes y URLs distintas.
Conclusión
Un reset rápido, una versión fija del contenedor y bases de datos clonadas mantienen el entorno estable y reproducible. Para soluciones más completas, se puede mirar tinbase.dev. Si se necesita una app móvil, RapidNative genera una base de React Native a partir de un prompt.
RapidNative
