Mejores prácticas para bases de datos

Migraciones en CI; nunca DDL manual en producción. Usa esta lista de verificación para equipos de Node.js que trabajan con Postgres, Prisma, Drizzle y MongoDB.

Cómo usar esta lista

• Condiciona los despliegues a producción al éxito de migrate deploy
• Revisa semanalmente los registros de consultas lentas en staging
• Combínalo con Ajuste del pool de conexiones antes de escalar réplicas
• Aplica las mismas reglas a workers y trabajos cron, no solo a las API HTTP

A - Esquema y migraciones

• Todo el DDL son archivos de migración versionados. No hay ALTER manual en las consolas de producción.
• Las migraciones se ejecutan en el pipeline de CI/CD antes de que la nueva revisión de la aplicación sirva tráfico.
• Migraciones compatibles con versiones anteriores para despliegues sin tiempo de inactividad (añade la columna como anulable primero).
• Los scripts de datos iniciales son idempotentes solo para desarrollo/staging, nunca se inicializa automáticamente la producción.
• Las adiciones de índices se revisan para la duración del bloqueo; usa CONCURRENTLY en Postgres cuando sea necesario.

B - Gestión de conexiones

• Un pool de conexiones por proceso por URL de base de datos.
• pool.max dimensionado con la fórmula de recuento de réplicas; se mantiene por debajo del 70% de max_connections.
• PgBouncer o RDS Proxy cuando se usa serverless o más de 20 réplicas de API.
• pool.end() / $disconnect() en SIGTERM en el apagado elegante.
• La sonda de preparación ejecuta SELECT 1 no solo la apertura del socket TCP.

C - Seguridad y rendimiento de las consultas

• Consultas parametrizadas en todas partes; $1 para pg, APIs ORM para Prisma/Drizzle.
• No hay endpoints de lista SELECT * ilimitados; se requiere paginación y selección de columnas.
• Comprobaciones N+1 en staging con registro de consultas o APM.
• Tiempo de espera de la sentencia configurado en el rol de Postgres (ej. 30s) como red de seguridad.
• Las transacciones se mantienen cortas; no hay HTTP saliente dentro de transacciones abiertas.

D - Arquitectura de la aplicación

• Módulo de repositorio o acceso a datos; las rutas no incrustan cadenas SQL.
• Tipos de dominio separados de los modelos ORM cuando los límites importan.
• Claves de idempotencia en los endpoints de escritura que los sistemas externos reintentan.
• Outbox o cola para efectos secundarios después de la confirmación, no antes.
• Las pruebas de integración usan Testcontainers o una base de datos de staging dedicada, no solo el portátil de desarrollo.

E - Operaciones y resiliencia

• Copias de seguridad automatizadas con restauración probada simulacro trimestral documentado.
• Recuperación a un punto en el tiempo habilitada en Postgres gestionado.
• Manual de procedimientos para interrupciones de la base de datos vinculado desde el servicio de guardia; consulta Modo de interrupción de la base de datos.
• Secretos en vault/SSM; no en cadenas de conexión en git.
• Monitorización: conexiones, CPU, disco, retraso de replicación, consultas lentas.

F - Específico de MongoDB (cuando se usa)

• Índices en cada filtro de consulta de producción.
• Presupuesto de tamaño de documento; no hay arrays incrustados ilimitados.
• Write concern majority para datos críticos.
• Campo de versionado de esquema en documentos para migraciones continuas.

Preguntas frecuentes

Relacionado

• Conceptos básicos de bases de datos - ejemplos introductorios
• Ajuste del pool de conexiones - matemáticas de dimensionamiento
• node-postgres (pg) - patrones de controlador
• Prisma - migraciones de esquema
• Modo de interrupción de la base de datos - respuesta a incidentes

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS activa), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.