PostgreSQL: el núcleo que no debería ser un detalle del stack.

Cada temporada aparece un almacén «más simple». Luego el producto necesita transacciones —operaciones que o se completan todas o no se aplican—, unicidad y un informe que cuadra. PostgreSQL sigue siendo nuestra apuesta por defecto en aplicaciones web serias: tipos ricos, JSONB cuando hace falta flexibilidad, y un SQL que el equipo —y el agente— pueden leer.

El riesgo con IA es generar migraciones —cambios al esquema de tablas e índices— que «funcionan» y dejan índices a medias o ON DELETE sin pensar. El humano firma el esquema. El agente puede proponer, rellenar seeds y escribir consultas; no decide la cardinalidad del dominio —cuántos pedidos tiene un cliente, qué pasa si borras una factura—.

En lenguaje llano: la base de datos es la memoria del negocio. Si está mal diseñada, el panel bonito muestra datos incorrectos con mucha confianza. Piénsalo como el almacén de una tienda: si mezclas tallas en la misma caja, el escaparate miente.

PostgreSQL ofrece además búsqueda de texto completo, LISTEN/NOTIFY para avisos en tiempo real y extensiones maduras. Para un panel Cloud o un SaaS de facturación no es un documento Mongo que se improvisa; es un modelo con reglas.

En Ambigram dibujamos el esquema con el cliente antes de que el agente genere cien migraciones. Tipos, relaciones y políticas de borrado se discuten en humano; la IA acelera el SQL repetitivo después de que el modelo esté claro.

Si el modelo está claro, Node, Python o el ORM —herramienta que traduce objetos a tablas— son intercambiables. Si no, ningún framework salva el viernes. PostgreSQL no debería ser un detalle del stack; debería ser el núcleo que todos —incluidos los agentes— respetan.