Base de Datos
Cada proyecto DYPAI incluye su propia base de datos PostgreSQL. Postgres completo — sin variantes recortadas — con los mismos tipos, constraints y SQL que usarías en cualquier sitio. Dedicada a tu proyecto, aislada del resto.
Tres formas de gestionarla
| Pídeselo a tu IA | "Crea una tabla orders con total, fecha y customer_id." — tu cliente de IA edita el schema vía MCP. Lo más rápido para la mayoría de tareas. |
| Editor visual | Entra en la pestaña Database para crear tablas, editar columnas y ver filas. Bueno para ajustes rápidos. |
| Editor SQL | Ejecuta cualquier SQL directamente. Bueno para migraciones complejas o queries que la UI no cubre. |
Cambiarás entre ellos según la tarea. Para un CRUD directo, la IA suele ser lo más rápido. Para inspeccionar datos, el editor visual. Para casos raros o lo que la IA falla, SQL.
Por debajo, la IA opera la base de datos con las herramientas MCP execute_sql, apply_migration (cambios de schema), get_app_tables (inspeccionar el schema) y manage_roles. El paquete local @dypai-ai/mcp añade manage_database y bulk_upsert para cargas masivas desde tu sistema de archivos.
Modelo de seguridad
La seguridad en DYPAI se aplica a nivel de endpoint, no a nivel de base de datos. No hay row-level security (RLS).
Eso significa: la base de datos confía en el workflow que la llama. Tus endpoints son la puerta. Si un endpoint filtra por ${current_user_id}, solo vuelven las filas de ese usuario. Si un endpoint no filtra, quien tenga acceso a ese endpoint ve todo.
Esto mantiene las cosas simples — razonas sobre el acceso en un sitio (el endpoint), no en dos (la tabla y el endpoint). Pero significa que cada endpoint que construyes es responsable de su propio filtrado. Más sobre esto en API Builder: Endpoints.
Nunca expongas tablas crudas
No construyas endpoints que devuelvan tablas enteras sin filtrar. Siempre escopa las queries al usuario actual, al registro pedido o a un check de rol explícito.
Schemas que puedes usar
Tu base de datos tiene varios schemas con reglas distintas:
public— tu schema. Lectura/escritura completa. Aquí van tus tablas.system— auth de usuarios, roles, metadata de endpoints, memoria de agentes. Solo lectura para tus queries. Puedes hacer JOINs desde aquí (p. ej.LEFT JOIN system.users).storage/auth— fontanería interna. Solo lectura. No escribas aquí.
El editor visual solo muestra public por defecto. El editor SQL te deja leer de los demás.
Copias de seguridad
Los backups automáticos diarios son una función de planes de pago — el plan Free no tiene backups automáticos. En un plan de pago los encuentras en Database → Backups, donde puedes descargar cualquier backup reciente. No hay botón de "restaurar" dentro de la app: descargas un backup y reimportas lo que necesites. La retención es una única ventana global (~7 días, configurada por entorno) — no escala por plan.
Mira Backups para el flujo completo.
Límites
| Free | De pago | |
|---|---|---|
| Tamaño de DB | 500 MB | Hasta 100 GB |
| Timeout de query | 30s | 30s |
El almacenamiento de base de datos es un límite a nivel de plan de la organización, compartido entre todas las apps de tu workspace, y se sigue en la página de Uso del proyecto (Observe → Usage). Si lo superas, se bloquean las escrituras hasta que liberes espacio o subas de plan. Las conexiones se sirven desde un backend con pool compartido (PgBouncer), así que no gestionas un límite de conexiones por proyecto directamente.