Base de datos: qué es y por qué tu app la necesita
Si estás aprendiendo a vibecoder — es decir, a construir apps con ayuda de la IA sin ser programador — hay un momento en que Claude o Cursor te va a decir algo como: "voy a crear una tabla en la base de datos para guardar los usuarios". Y si nunca has tocado una base de datos en tu vida, esa frase puede sonar intimidante.
Este artículo es para que ese momento no te frene. Vamos a ver qué es una base de datos, cómo funciona por dentro, y por qué cualquier app mínimamente útil la necesita — con ejemplos reales que cualquiera puede entender.
1. Por qué tu app necesita "memoria"
1.1 El problema de guardar información
Imagina que construyes una app sencilla de lista de tareas. Añades una tarea: "Llamar a María el lunes". Cierras la app. La abres al día siguiente.
¿Está la tarea? Depende de dónde se guarde esa información.
Si solo vive en la pantalla — en lo que se llama la "memoria temporal" del navegador — desaparece en cuanto cierras la pestaña. Exactamente igual que cuando borras una nota mental: si no la escribes en algún sitio, se pierde.
Una app útil necesita persistencia: que los datos sobrevivan más allá de la sesión actual, que estén disponibles desde distintos dispositivos y que puedan consultarse, modificarse y borrarse de forma organizada.
Para eso existe la base de datos.
1.2 Lo que ocurre sin base de datos
Sin una base de datos, cada vez que un usuario abre tu app empieza desde cero. No hay historial, no hay configuración guardada, no hay nada que pertenezca a ese usuario de forma permanente.
Puedes usar soluciones parciales — como guardar cosas en el almacenamiento local del navegador (localStorage) — pero esas soluciones tienen un problema grave: no se comparten entre dispositivos ni entre usuarios. Si alguien usa tu app desde el móvil y luego desde el portátil, ve dos mundos distintos.
Una base de datos es el lugar donde tu app guarda todo lo que importa para que persista, sea accesible desde cualquier sitio y pueda compartirse entre usuarios.
2. Qué es una base de datos
2.1 La metáfora de la hoja de cálculo
La forma más fácil de entender una base de datos es compararla con una hoja de cálculo de Excel o Google Sheets.
Cuando abres una hoja de cálculo y organizas información en filas y columnas — por ejemplo, una lista de clientes con su nombre, email y teléfono — estás haciendo exactamente lo que hace una base de datos, pero de forma manual y limitada.
Una base de datos relacional hace lo mismo, pero:
- Puede manejar millones de filas sin perder velocidad
- Permite buscar, filtrar y ordenar información en milisegundos
- Garantiza que los datos sean consistentes y no estén duplicados
- Puede tener múltiples hojas relacionadas entre sí (esto es la clave, y lo vemos en el siguiente apartado)
La diferencia entre una hoja de cálculo y una base de datos es como la diferencia entre una libreta y un archivo de empresa: sirven para lo mismo, pero una escala y la otra no.
2.2 Tablas, filas y columnas
Una base de datos se organiza en tablas. Cada tabla representa un tipo de entidad: usuarios, tareas, productos, pedidos, mensajes...
Dentro de cada tabla:
- Las columnas definen qué tipo de información se guarda (nombre, email, fecha de creación, precio...)
- Las filas son los registros individuales (cada usuario concreto, cada tarea concreta, cada producto concreto)
Por ejemplo, una tabla de usuarios podría tener esta pinta:
| id | nombre | fecha_registro | |
|---|---|---|---|
| 1 | Ana García | ana@ejemplo.com | 2026-01-10 |
| 2 | Luis Martínez | luis@ejemplo.com | 2026-02-03 |
| 3 | Marta López | marta@ejemplo.com | 2026-03-15 |
Cada fila es un usuario. Cada columna es un dato de ese usuario. Simple.
Lo importante es la columna id: es el identificador único de cada fila. Ningún usuario tiene el mismo id. Esto es fundamental para poder relacionar tablas entre sí, que es donde empieza la magia real.
3. Relaciones entre tablas
3.1 Por qué no lo metemos todo en una sola tabla
Aquí viene el concepto que hace poderosas a las bases de datos: las relaciones.
Imagina que tienes una tienda online. Podrías intentar meterlo todo en una sola tabla:
| pedido_id | cliente_nombre | cliente_email | producto | precio |
|---|---|---|---|---|
| 1 | Ana García | ana@ejemplo.com | Camiseta azul | 25€ |
| 2 | Ana García | ana@ejemplo.com | Pantalón negro | 45€ |
| 3 | Luis Martínez | luis@ejemplo.com | Camiseta azul | 25€ |
¿Ves el problema? El nombre y el email de Ana aparecen dos veces. Si Ana cambia su email, tienes que actualizarlo en todas las filas donde aparece. Si se te olvida una, tienes datos contradictorios. Esto se llama redundancia de datos y es una pesadilla en apps reales.
La solución es separar la información en tablas distintas y conectarlas.
3.2 Cómo se conectan las tablas
En lugar de repetir el nombre y email del cliente en cada pedido, guardas solo su id:
Tabla clientes:
| id | nombre | |
|---|---|---|
| 1 | Ana García | ana@ejemplo.com |
| 2 | Luis Martínez | luis@ejemplo.com |
Tabla pedidos:
| id | cliente_id | producto | precio |
|---|---|---|---|
| 1 | 1 | Camiseta azul | 25€ |
| 2 | 1 | Pantalón negro | 45€ |
| 3 | 2 | Camiseta azul | 25€ |
Ahora cliente_id en la tabla de pedidos apunta a la tabla de clientes. La base de datos sabe que el pedido 1 y el pedido 2 son de Ana (id=1) sin necesidad de repetir su nombre y email.
Cuando Ana cambia su email, lo cambias en un solo sitio — en la tabla clientes, fila 1 — y automáticamente todos sus pedidos apuntan a la información correcta.
Esto se llama clave foránea (foreign key): un campo en una tabla que hace referencia al id de otra tabla. Es el mecanismo que conecta tablas entre sí y evita la duplicación de datos.
4. Ejemplos reales
4.1 Una lista de tareas
La app más sencilla del mundo — una to-do list — ya necesita una base de datos si quieres que funcione de verdad.
Sin base de datos: las tareas desaparecen al cerrar el navegador.
Con base de datos, tienes al menos una tabla tareas:
| id | usuario_id | titulo | completada | fecha_limite |
|---|---|---|---|---|
| 1 | 42 | Llamar a María | false | 2026-04-20 |
| 2 | 42 | Revisar presupuesto | true | 2026-04-15 |
| 3 | 87 | Enviar informe | false | 2026-04-18 |
Cada tarea pertenece a un usuario (via usuario_id). Puedes filtrar las tareas de un usuario concreto, ordenarlas por fecha límite, marcarlas como completadas...
Y si luego quieres añadir etiquetas o categorías a las tareas, añades una tabla categorias y una tabla intermedia tareas_categorias. Así de escalable es este modelo.
4.2 Una tienda online
Una tienda online tiene más entidades que una lista de tareas, pero el principio es el mismo.
Las tablas típicas son:
- productos — id, nombre, descripción, precio, stock
- clientes — id, nombre, email, dirección
- pedidos — id, cliente_id, fecha, estado (pendiente/enviado/entregado)
- lineas_pedido — id, pedido_id, producto_id, cantidad, precio_unitario
Esa última tabla — lineas_pedido — es un ejemplo de tabla intermedia que conecta pedidos con productos. Un pedido puede tener varios productos, y un producto puede aparecer en varios pedidos. Esto se llama relación muchos a muchos.
Lo interesante es que con esta estructura puedes responder preguntas como "¿cuáles son los 10 productos más vendidos este mes?" o "¿cuánto ha gastado este cliente en total?" — en milisegundos, aunque tengas 100.000 pedidos.
4.3 Un CRM sencillo
Un CRM (Customer Relationship Manager) es básicamente un sistema para llevar el seguimiento de clientes potenciales y contactos. Muchos negocios pequeños lo hacen con una hoja de cálculo, pero cuando empiezas a crecer, necesitas algo más robusto.
Un CRM mínimo viable tiene tablas como:
- contactos — id, nombre, empresa, email, teléfono, estado (lead/cliente/inactivo)
- interacciones — id, contacto_id, tipo (llamada/email/reunión), notas, fecha
- oportunidades — id, contacto_id, valor_estimado, probabilidad, fecha_cierre_estimada
Con estas tres tablas puedes saber qué contactos están en qué fase, cuándo fue el último contacto con cada uno, cuánto dinero potencial hay en el pipeline...
La clave es que una base de datos bien diseñada no solo guarda datos — los estructura de forma que puedas hacer preguntas útiles sobre ellos. Eso es lo que la diferencia de un montón de archivos sueltos.
5. Las bases de datos más usadas en apps con IA
5.1 SQL vs NoSQL: la diferencia que importa
Hay dos grandes familias de bases de datos:
SQL (relacionales): Organizan los datos en tablas con esquema fijo (como los ejemplos que hemos visto). Son las más usadas en el mundo y las más documentadas. PostgreSQL, MySQL y SQLite son las más populares. La IA las entiende muy bien porque hay muchísimo material de entrenamiento sobre ellas.
NoSQL: Guardan los datos en formatos más flexibles (como documentos JSON, pares clave-valor o grafos). Son más fáciles de empezar para ciertas apps, pero menos predecibles. MongoDB y Firebase Realtime Database son ejemplos conocidos.
Para la mayoría de apps que vas a construir vibecodering, SQL es la mejor opción. La razón es práctica: como PostgreSQL es el más documentado del mundo, la IA genera código más preciso y con menos errores cuando trabajas con SQL.
Además, si describes tu app a Claude, hay muchas más probabilidades de que sugiera una estructura SQL correcta desde el primer intento.
5.2 Supabase, Firebase y otras opciones para vibecoders
El mayor freno para los no programadores no es entender las bases de datos, sino configurarlas. Históricamente, instalar y mantener un servidor de base de datos era algo reservado a desarrolladores con experiencia.
Hoy eso ha cambiado radicalmente. Las opciones más populares para vibecoders son:
-
Supabase — La opción más recomendada en 2026 para apps vibecodered. Usa PostgreSQL (SQL estándar), tiene una interfaz visual para ver y editar tus tablas, autenticación de usuarios incluida, y una capa de seguridad (RLS) que controla quién puede ver qué. Además, tiene un tier gratuito generoso para proyectos en desarrollo.
-
Firebase — La opción histórica de Google. Más rápida de arrancar para prototipos simples, pero usa NoSQL, lo que a veces complica el diseño cuando la app crece. Sigue siendo válida para apps muy orientadas a tiempo real.
-
PlanetScale / Neon — Bases de datos SQL serverless. Buena opción si ya sabes que vas a usar SQL y quieres algo muy escalable desde el principio.
Para la mayoría de proyectos que arrancan con IA, Supabase es el punto de partida más cómodo: Claude lo conoce bien, la documentación es excelente, y puedes ver tus datos en una tabla visual sin tocar ningún terminal.
6. Claude y las bases de datos
6.1 Cómo pedirle a Claude que diseñe tu base de datos
Una de las cosas más poderosas del vibecoding es que puedes pedirle a Claude que diseñe la estructura de base de datos de tu app sin saber nada de SQL.
El truco es describir tu app en términos de negocio, no de tecnología. En lugar de decir "necesito tablas relacionadas con clave foránea", dices:
"Estoy construyendo una app para gestionar reservas de una consulta de fisioterapia. Los pacientes pueden reservar citas con distintos fisioterapeutas. Cada cita tiene una duración, un estado (pendiente/confirmada/cancelada) y notas del tratamiento. ¿Qué tablas necesito y cómo las conectarías?"
Claude va a responder con una propuesta de tablas, columnas y relaciones. Puede incluso generar el SQL para crearlas en Supabase o el código necesario para inicializar la base de datos.
Lo importante es que tú aportas el conocimiento del negocio (qué entidades existen, cómo se relacionan en la vida real) y Claude traduce eso a estructura técnica.
6.2 Preguntas que puedes hacer sin saber SQL
No tienes que aprender SQL para trabajar con bases de datos vibecodering. Pero sí te ayuda saber qué tipo de preguntas puedes hacerle a Claude para que te ayude:
- "¿Qué tablas necesito para esta app?"
- "¿Cómo relaciono la tabla de usuarios con la de pedidos?"
- "Tengo esta estructura, ¿qué le falta para manejar [caso de uso concreto]?"
- "Dame una consulta SQL para ver todos los pedidos de este mes ordenados por importe"
- "¿Cómo configuro los permisos en Supabase para que cada usuario solo vea sus propios datos?"
La clave es ser específico sobre tu caso de uso. Cuanto más contexto le das a Claude sobre qué hace tu app y cómo la usan los usuarios reales, mejor será la estructura que proponga.
Y si la propuesta no se ajusta del todo, puedes dialogar: "en mi caso los clientes pueden tener múltiples direcciones de envío, ¿cómo cambiaría esto?". Claude ajusta. Así de iterativo es el proceso.
Las bases de datos no son magia oscura reservada a programadores de élite. Son hojas de cálculo muy potentes con superpoderes. Y con herramientas como Supabase y un buen copiloto como Claude, puedes diseñar, crear y gestionar la base de datos de tu app sin necesidad de saber SQL de memoria ni haber estudiado informática.
Lo que sí necesitas es entender el concepto: tablas, filas, columnas y relaciones. Con eso claro, Claude hace el resto.
Si quieres aprender a construir tu primera app con base de datos incluida — desde cero, paso a paso, en español — echa un vistazo a Claudio Academy. Tenemos lecciones específicas sobre cómo configurar Supabase y cómo pedirle a Claude que gestione tu base de datos por ti.
¿Quieres dominar la IA con Claude?
Más de 20 horas de vídeo en español para pasar de cero a experto. Pago único de 49€, acceso de por vida.
Ver el curso