Habilidades postgres-best-practices

📦

postgres-best-practices

Name: postgres-best-practices
Author: sickn33

Seguro

Optimizar consultas y esquemas de PostgreSQL

¿Problemas con consultas de base de datos lentas y bajo rendimiento? Esta habilidad proporciona reglas de optimización de PostgreSQL probadas en producción de Supabase con ejemplos concretos de SQL y mejoras de rendimiento medibles.

Soporta: Claude Codex Code(CC)

📊 71 Adecuado

Descargar el ZIP de la skill

Subir en Claude

Ve a Configuración → Capacidades → Skills → Subir skill

Activa y empieza a usar

Pruébalo

Usando "postgres-best-practices". This query takes 5 seconds on 100k rows: SELECT * FROM orders WHERE customer_id = 42 AND status = 'pending'

Resultado esperado:

Crear un índice compuesto: CREATE INDEX idx_orders_customer_status ON orders (customer_id, status). Esto cambia el plan de ejecución de scan secuencial a scan por índice, reduciendo el tiempo de consulta a menos de 10ms. El orden de las columnas importa: coloca el filtro de igualdad (customer_id) antes del filtro de status para un uso óptimo del índice.

Usando "postgres-best-practices". How do I prevent N+1 queries when fetching users with their profile data?

Resultado esperado:

Reemplazar consultas individuales con un JOIN: SELECT u.*, p.bio, p.avatar_url FROM users u LEFT JOIN user_profiles p ON p.user_id = u.id. Añadir un índice en user_profiles(user_id) para búsquedas rápidas. Esto reduce 101 consultas (1 para usuarios + 100 para perfiles) a una sola consulta.

Auditoría de seguridad

Seguro

v1 • 2/24/2026

This skill contains educational documentation for PostgreSQL best practices from Supabase. All 711 static analysis findings are false positives: the 'external_commands' detections are SQL code blocks in markdown documentation (not shell commands), 'network' URLs are reference links to postgresql.org and supabase.com, 'scripts' findings are SQL WITH clauses (CTEs), and 'crypto' warnings are text pattern matches in documentation. No executable code or security risks present.

Archivos escaneados

3,490

Líneas analizadas

hallazgos

Auditorías totales

No se encontraron problemas de seguridad

Auditado por: claude

Puntuación de calidad

Arquitectura

100

Mantenibilidad

Contenido

Comunidad

100

Seguridad

Cumplimiento de la especificación

Lo que puedes crear

Desarrollador backend optimizando consultas lentas

Identificar índices faltantes, corregir patrones N+1 y aplicar técnicas de optimización de consultas para reducir tiempos de respuesta de segundos a milisegundos.

Arquitecto de bases de datos diseñando nuevos esquemas

Aplicar mejores prácticas para tipos de datos, restricciones, claves foráneas y estrategias de indexación durante el diseño inicial del esquema.

Ingeniero DevOps ajustando bases de datos en producción

Configurar límites de conexión, ajustes de vacuum y monitoreo para mantener la salud de la base de datos bajo carga.

Prueba estos prompts

Optimización básica de consultas

Review this PostgreSQL query for performance issues and suggest improvements: [paste query]

Recomendación de índices

Analyze this table schema and query workload. What indexes should I create for optimal performance? Schema: [paste schema], Queries: [paste queries]

Corrección de consulta N+1

I'm fetching users and their orders with separate queries. Show me how to rewrite this as a single efficient JOIN with proper indexing.

Política de Row-Level Security

Create a Row-Level Security policy for a multi-tenant SaaS where users can only access data belonging to their organization. Table structure: [paste schema]

Mejores prácticas

Siempre añadir índices en columnas WHERE, JOIN y ORDER BY
Usar EXPLAIN ANALYZE para verificar planes de ejecución de consultas antes de desplegar
Implementar agrupación de conexiones para prevenir agotamiento de la base de datos

Evitar

Ejecutar consultas sin índice en tablas grandes causando scans secuenciales
Obtener todas las columnas con SELECT * en lugar de campos específicos
Usar LIKE con comodines iniciales lo cual previene el uso de índices

Preguntas frecuentes

¿Cómo sé qué columnas necesitan índices?

Indexar columnas usadas en cláusulas WHERE, condiciones JOIN, ORDER BY y claves foráneas. Usar pg_stat_user_tables para identificar columnas accedidas frecuentemente sin índices.

¿Qué es N+1 y cómo lo corrijo?

N+1 ocurre cuando obtienes un registro padre luego haces N consultas adicionales para registros hijos. Se corrige usando JOINs o carga por lotes con cláusulas IN para obtener todos los hijos en una consulta.

¿Cuándo debo usar índices parciales?

Usar índices parciales cuando las consultas filtran frecuentemente en una condición específica (ej. WHERE status='active'). Esto crea índices más pequeños y rápidos cubriendo solo filas relevantes.

¿Cómo funciona Row-Level Security?

RLS aplica políticas de acceso a nivel de base de datos. Habilitar con ALTER TABLE ... ENABLE ROW LEVEL SECURITY, luego crear políticas que filtren filas basadas en atributos de usuario como organization_id.

¿Qué tamaño de pool de conexiones debo usar?

Comenzar con 10-20 conexiones por instancia de aplicación. Monitorear pg_stat_activity y ajustar basándose en: (CPU cores * 2) + effective_spindle_count para cargas de trabajo limitadas por CPU.

¿Por qué mis consultas son lentas después de añadir índices?

Causas posibles: orden incorrecto de columnas en índices compuestos, usar funciones en columnas indexadas, estadísticas desactualizadas (ejecutar ANALYZE), o índices en columnas de baja cardinalidad. Usar EXPLAIN ANALYZE para diagnosticar.