Base de datos
La API usa Supabase (PostgreSQL) como base de datos, con Row Level Security (RLS) habilitado en tablas sensibles. Las migraciones se gestionan con archivos SQL enapps/backend/src/database/migrations/.
Tablas principales
Users y autenticación
Tabla
users:
Chat
Community
Surveys
Tabla
surveys:
Tabla
survey_responses:
Índices y constraints:
- Partial unique index: máximo 1 versión
activeporsurvey_type_id - Índices en
survey_responses: porsurvey_id+status,scope_id+survey_id,respondent_id - Unique constraint: 1 reward por response, 1 recommendation por response, 1 action plan por survey + scope
Notificaciones e inbox
Tabla
inbox_messages:
Permisos
Sync (Windmill)
AI / Insights
Tabla
survey_insights:
Integraciones
Row Level Security (RLS)
Las tablas sensibles tienen políticas RLS habilitadas:inbox_messages: Los usuarios solo pueden leer y actualizar sus propios mensajes. Los admin pueden acceder a todos. El service role puede insertar mensajes (para integraciones y notificaciones del sistema).- Otras tablas con datos de usuario siguen patrones similares.
Migraciones
Las migraciones SQL se encuentran enapps/backend/src/database/migrations/ y se ejecutan en orden numérico. Cada migración crea tablas, índices y políticas RLS necesarias.
Política de migraciones
Reglas:- Una migración se commitea una vez. Después solo se modifican comentarios.
- Cambios estructurales = nueva migración con
ALTER TABLE/ALTER INDEX/DROP COLUMN/ etc. Siempre conIF NOT EXISTScuando sea posible para que sea idempotente. - Antes de mergear a
develop: ejecutarpnpm --filter @vivla-tools/backend db:migratelocalmente contra una copia de dev para confirmar que corre limpia. - Tras el merge: aplicar a dev inmediatamente.
apps/backend/scripts/check-migration-edits.sh bloquea commits que tocan .sql ya presentes en origin/main (excepto cambios solo en comentarios). Bypass con git commit --no-verify solo para hotfixes reales.