Mejores prácticas de psql

Hábitos seguros para SQL interactivo, clientes GUI y comprobaciones automatizadas contra PostgreSQL de producción.

Cómo usar esta lista

• Incorpora a todos los ingenieros que manipulan datos de producción con las secciones A y B primero.
• Aplica B y C mediante permisos de roles; la cultura por sí sola falla a las 2 AM.
• Reaudita trimestralmente cuando aparezcan nuevas herramientas de BI o hosts de acceso.

A - Seguridad de la conexión

• Acceso por defecto a producción a través de réplicas de lectura. La primaria es solo para escrituras y migraciones controladas.
• Usa roles de solo lectura (app_ro) para la exploración. Sin INSERT/UPDATE/DELETE en rutas humanas de producción.
• Establece application_name para identificar a los humanos. PGAPPNAME=psql-alice en los perfiles del jump box.
• Requiere TLS para psql remoto. sslmode=verify-full cuando la CA sea manejable.
• Nunca almacenes contraseñas de producción en el historial del shell. Usa ~/.pgpass con permisos 600 o un CLI de bóveda.

B - Disciplina de consultas

• Siempre usa LIMIT en SELECT no acotados para exploración. Combina con ORDER BY cuando el orden importe.
• Habilita \timing para investigaciones de rendimiento. Sigue con EXPLAIN en staging antes de ANALYZE en producción.
• Evita SELECT * en tablas anchas en producción. Nombra las columnas explícitamente; las filas JSONB son costosas.
• Usa BEGIN READ ONLY para exploración de múltiples sentencias. Previene escrituras accidentales en la misma sesión.
• Establece statement_timeout en roles humanos. 30s-120s típico para SQL ad-hoc.

C - Scripting y Automatización

• Usa -v ON_ERROR_STOP=1 en todos los scripts psql de CI. El éxito parcial es peor que un fallo ruidoso.
• Prefiere \copy sobre COPY de ruta de servidor para operadores. Menos privilegios de archivo de superusuario.
• Envuelve scripts DDL en transacciones cuando sea seguro. Conoce las excepciones: CREATE INDEX CONCURRENTLY no puede.
• Registra el nombre del script a través de PGAPPNAME. Aparece en pg_stat_activity durante las pruebas de humo de despliegue.
• Controla la versión de cada script SQL no trivial. Un fix.sql ad-hoc en el portátil no es un runbook.

D - Clientes GUI

• Codifica por color los servidores de producción vs staging en pgAdmin/DBeaver. Rojo/verde o prefijos de host distintos.
• Deshabilita las ediciones de cuadrícula con confirmación automática en perfiles de producción. Roles de solo lectura como aplicación de respaldo.
• Prohíbe las conexiones de superusuario guardadas en portátiles. Las credenciales de "break-glass" viven en la bóveda con TTL.
• Dirige a los usuarios de GUI a través de las mismas políticas de tiempo de espera que psql. idle_in_transaction_session_timeout obligatorio.
• Exporta grandes conjuntos de datos con COPY, no con exportación por clic de GUI. Evita OOM del cliente en errores de un millón de filas.

E - Normas del equipo

• Enseña los metacomandos de psql antes de la incorporación solo GUI. \d, \conninfo, \timing reducen los clics mágicos.
• Documenta las versiones de cliente aprobadas en la incorporación. La discrepancia de versión principal entre cliente/servidor rompe dump/restore.
• Revisión post-incidente cuando ocurre una escritura en el entorno incorrecto. Actualiza alias y colores del jump box, no solo culpas.
• Sanea los volcados antes de restaurar en desarrollo. pg_dump desde producción a un portátil es una ruta de brecha de datos.
• Empareja el SQL analítico con estándares de revisión de EXPLAIN. Consulta la documentación de revisión de consultas para las puertas de fusión.

Preguntas frecuentes

Relacionado

• Conceptos básicos de psql - conectar, timing, LIMIT
• pgAdmin & DBeaver - salvaguardas GUI
• Mejores prácticas de permisos - diseño de roles

Versiones de pila: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.