supabase-postgres-best-practices
Optimiza el Rendimiento de Postgres con Mejores Prácticas de Expertos
También disponible en: supabase
Las consultas lentas y el diseño deficiente del esquema afectan a las aplicaciones Postgres. Esta habilidad proporciona 26 reglas priorizadas de expertos de Supabase para lograr mejoras de rendimiento de 10-1000x.
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 "supabase-postgres-best-practices". Review my Postgres query and suggest optimizations based on best practices: SELECT * FROM events WHERE user_id = 123 ORDER BY created_at DESC LIMIT 20
Resultado esperado:
Basado en las reglas de query-missing-indexes.md, tu consulta necesita un índice en las columnas de filtro y orden:
1. Agrega índice compuesto:
```sql
CREATE INDEX events_user_id_created_at_idx
ON events (user_id, created_at DESC);
```
2. Mejora esperada: Index scan reduce el costo de 25,000 a 8.44 (100-1000x más rápido en tablas grandes).
3. Para consultas LIMIT, considera usar covering indexes para evitar búsquedas en tabla si solo necesitas columnas específicas.
Usando "supabase-postgres-best-practices". Is this batch insert pattern following best practices? for (let i = 0; i < 1000; i++) { await db.query('INSERT INTO logs (message) VALUES ($1)', [logs[i]]); }
Resultado esperado:
No, esto viola las reglas de data-batch-inserts.md. Tienes:
- 1000 idas y vueltas individuales
- 1000 transacciones separadas
- Estimado 10-50x más lento de lo necesario
Enfoque correcto (de las reglas):
```sql
INSERT INTO logs (message) VALUES
($1), ($2), ($3), ... hasta ~1000 filas;
```
O usa COPY para importaciones masivas (método más rápido). Ver data-batch-inserts.md para ejemplos.
Usando "supabase-postgres-best-practices". Should I add an index on this foreign key column that gets queried occasionally?
Resultado esperado:
Sí, absolutamente. De schema-foreign-key-indexes.md:
**Impacto: CRÍTICO (mejora de 5-20x)**
Las columnas de clave foránea casi siempre deben estar indexadas porque:
1. Los JOINs en claves foráneas causan escaneos secuenciales sin índices
2. Los DELETEs en tablas padre requieren escanear tablas hijas
3. Las operaciones en cascada se vuelven exponencialmente más lentas en tablas grandes
La regla nota: Incluso consultas ocasionales se benefician de indexar claves foráneas debido a costos de escaneo exponenciales.
Auditoría de seguridad
SeguroAll 710 static findings are false positives. This is a documentation-only skill containing Postgres best practices in Markdown format. The flagged patterns (backticks, MD5 references, URLs, system queries) are all legitimate SQL examples, documentation links, and monitoring queries. No executable code, no data exfiltration, no malicious intent detected.
Problemas de riesgo medio (1)
Problemas de riesgo bajo (4)
Factores de riesgo
⚡ Contiene scripts (1)
⚙️ Comandos externos (2)
🌐 Acceso a red (2)
Puntuación de calidad
Lo que puedes crear
Resolución de Problemas de Rendimiento de Consultas
Desarrollador que experimenta endpoints de API lentos usa reglas de optimización de consultas para agregar índices y reescribir consultas para mejora de 100-1000x.
Revisión de Diseño de Esquema de Base de Datos
Arquitecto de base de datos revisa reglas de diseño de esquema antes de lanzar aplicación SaaS multi-tenant para evitar refactorización costosa.
Planificación de Migración Postgres
Ingeniero DevOps planifica migración de arquitectura single-tenant a multi-tenant usando guías de RLS y connection pooling.
Prueba estos prompts
I have a slow Postgres query. Help me optimize it using best practices from the supabase-postgres-best-practices skill. My query: ```sql SELECT * FROM orders WHERE customer_id = 123 AND status = 'pending' ``` Table has 10 million rows. Query takes 5 seconds.
Review my indexing strategy for this schema using the supabase-postgres-best-practices skill. Focus on composite indexes, partial indexes, and foreign key indexing. Schema: - users table (1M rows) - orders table (5M rows, foreign key to users) - Query pattern:经常 filter by user_id + created_at + status
I'm implementing Row-Level Security for multi-tenant data using supabase-postgres-best-practices. Help me optimize RLS policies. Current policy: ```sql CREATE POLICY user_isolation ON documents USING (auth.uid() = user_id) WITH CHECK (auth.uid() = user_id); ``` Query performance degraded 5x after enabling RLS.
Help me configure connection pooling for a Node.js application with Supabase using supabase-postgres-best-practices. Requirements: - 1000 concurrent users - Average query time: 50ms - Using PgBouncer - Experiencing connection exhaustion errors Provide specific configuration values and explain trade-offs.
Mejores prácticas
- Siempre crea índices en columnas WHERE, JOIN y ORDER BY antes de desplegar a producción
- Usa paginación basada en cursor con columnas indexadas en lugar de OFFSET para conjuntos de resultados grandes
- Mantén transacciones cortas (menos de 1 segundo) y evita interacción del usuario a mitad de transacción para prevenir contención de bloqueos
Evitar
- Usar SELECT * en tablas grandes cuando solo se necesitan columnas específicas (causa I/O innecesario y previene optimización de covering index)
- Ejecutar sentencias INSERT individuales dentro de bucles en lugar de lotes de filas o usar COPY
- Crear índices sin analizar patrones de consulta con EXPLAIN ANALYZE (algunos índices pueden perjudicar el rendimiento de escritura sin ayudar a lectura)
Preguntas frecuentes
¿Cómo sé qué columnas necesitan índices?
¿Debo indexar cada clave foránea?
¿Por qué la paginación basada en cursor es mejor que OFFSET?
¿Cuántos connection poolers necesito para Supabase?
¿Row-Level Security (RLS) afecta el rendimiento?
¿Puedo usar estas reglas con PostgreSQL crudo o solo Supabase?
Detalles del desarrollador
Estructura de archivos