# Qué es una base de datos y para qué sirve

**Categoría:** Datos y bases de datos · **Nivel:** Inicial · **Lectura:** 13 min
**Publicada:** 2026-07-27 · **Actualizada:** 2026-07-27 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/bases-de-datos/que-es-una-base-de-datos/

Qué resuelve una base de datos que una planilla no puede, qué es un motor o DBMS, integridad, concurrencia, transacciones y el panorama de tipos que existen.

## Respuesta rápida

Una **base de datos** es una colección organizada de datos administrada por un programa llamado **motor** o **DBMS**. Su valor no está en almacenar —eso también lo hace un archivo— sino en **cuatro garantías**: que cada dato exista una sola vez, que no se pueda guardar un valor inválido, que varias personas escriban a la vez sin pisarse, y que una operación que toca varios registros se complete entera o no se complete. Esas cuatro garantías son la razón por la que una planilla deja de servir cuando los datos se comparten y crecen.

## Qué es, con precisión

Una **base de datos** es una colección de datos organizada de forma que se pueda consultar, modificar y proteger de manera confiable. Casi todas las definiciones que vas a encontrar dicen algo parecido, y casi todas se quedan cortas en la parte importante: *qué significa «confiable»*.

La forma más rápida de entenderlo es mirar el problema que la hizo necesaria. Antes de las bases de datos, cada programa guardaba sus propios archivos con su propio formato. Si dos programas necesitaban los mismos datos, había dos copias. Cuando una cambiaba, la otra quedaba vieja, y nadie sabía cuál era la correcta. Todo lo que sigue en esta guía es, en el fondo, una solución a ese problema.

> **La idea que conviene llevarse:** una base de datos no es un depósito: es un **guardián**. Su trabajo no es solo tener los datos, sino impedir activamente que se corrompan, se dupliquen o se contradigan. Cuando entendés eso, todo lo demás —las claves, los tipos de dato, las restricciones— deja de parecer burocracia y empieza a tener sentido.

Esta guía abre una serie de seis. Acá vemos el concepto; después vienen [el modelo relacional](../bases-de-datos-relacionales-y-tablas/index.md), [SQL](../introduccion-a-sql-desde-cero/index.md), [el diseño](../como-disenar-una-base-de-datos-sencilla/index.md), [MySQL](../mysql-instalacion-y-primeros-pasos/index.md) y [la comparación con las no relacionales](../relacional-vs-no-relacional/index.md).

## Por qué no alcanza una planilla

Esta es la pregunta que más se hace y la que mejor explica todo lo demás, así que vale la pena verla con datos concretos.

![Comparación de dos formas de guardar los mismos pedidos. A la izquierda, una planilla de una sola hoja donde el nombre y el correo de la clienta se repiten en cada fila, con una fila donde el nombre está escrito distinto, otra con el correo incompleto y otra con texto en la columna de precio. Se marcan cuatro problemas. A la derecha, los mismos datos en dos tablas relacionadas: clientes guarda cada persona una vez con un identificador, y pedidos referencia ese identificador. Se listan cuatro garantías.](../../assets/img/guias/que-es-una-base-de-datos-planilla-vs-base.svg)

*El mismo pedido de tres productos, guardado de dos maneras. Los errores de la izquierda no son inventados: aparecen solos cuando el dato se repite.*

Fijate en lo que pasa en la planilla. El nombre de la clienta está escrito de dos formas distintas —«Ana López» y «Ana Lopez»—, porque nada obliga a que sea igual. A un correo le falta una letra. Y en la columna de precio hay un texto en lugar de un número, así que ya no se puede sumar la columna.

Ninguno de esos tres errores requiere mala intención ni descuido especial: **aparecen solos** cuando el mismo dato se escribe muchas veces. Y con veinte filas se detectan a ojo; con veinte mil, no.

Del lado de la base de datos, el nombre de Ana está una sola vez, en una tabla `clientes`. La tabla `pedidos` no repite el nombre: guarda el número que identifica a esa clienta. Si Ana cambia de correo, se edita un solo lugar y los tres pedidos quedan actualizados, porque nunca tuvieron una copia.

> **Para que quede claro:** una planilla no está mal hecha: está pensada para otro problema. Es excelente para calcular, explorar y presentar. El límite aparece cuando los datos **se comparten, cambian y crecen**, que es exactamente el terreno de una base de datos.

## Base de datos y motor no son lo mismo

Es la confusión de vocabulario más común y vale corregirla temprano, porque ordena todo lo que viene después.

- La **base de datos** son los datos y su estructura: las tablas, sus columnas, sus vínculos.
- El **motor** es el programa que administra esa base: recibe consultas, las ejecuta, controla permisos, hace cumplir las reglas y escribe en disco. En inglés se lo llama **DBMS** (*database management system*), o **RDBMS** cuando es relacional. La documentación de PostgreSQL usa ese término para describirse a sí mismo: «un sistema para administrar datos guardados en relaciones».

MySQL, PostgreSQL, SQL Server, Oracle y SQLite son motores. Dentro de cualquiera de ellos podés crear muchas bases de datos. La distinción importa en la práctica porque casi todo lo que se aprende —usuarios y permisos, respaldos, rendimiento, tipos de dato disponibles— es del motor, no de la base.

Un caso que rompe el molde y conviene conocer: **SQLite** no tiene servidor. Es una biblioteca que guarda toda la base en un único archivo, y por eso está dentro de tu teléfono, tu navegador y buena parte de las aplicaciones de escritorio que usás. Es una base de datos completa sin nada que instalar ni administrar.

## Las cuatro garantías

Acá está el corazón de la respuesta a «para qué sirve». Estas cuatro cosas son las que un archivo o una planilla no pueden asegurar.

1. **Integridad.** El motor rechaza lo que no cumple las reglas. Si una columna es numérica, no entra texto. Si un pedido tiene que pertenecer a un cliente existente, no se puede crear apuntando a uno que no existe. La regla se define una vez y se aplica siempre, sin depender de que alguien se acuerde.
2. **Concurrencia.** Varias personas —o varios programas— pueden leer y escribir a la vez sin corromper nada y sin pisarse. Es la diferencia entre un archivo compartido en una carpeta de red y un sistema que puede atender a mil personas al mismo tiempo.
3. **Consultas.** Podés preguntar cosas complejas y obtener la respuesta exacta: «cuánto vendimos por mes en la provincia X, solo de clientes que compraron más de tres veces». En una planilla eso es una tarde de trabajo manual; acá es una consulta.
4. **Durabilidad.** Cuando el motor confirma que guardó algo, está guardado, incluso si se corta la luz un segundo después. Suena obvio y no lo es: escribir en disco tiene capas de memoria intermedia, y garantizar esto es trabajo serio de ingeniería.

Hay una quinta que se suele nombrar aparte porque merece su propia explicación, y es la que sigue.

## Transacciones: todo o nada

Una **transacción** agrupa varias operaciones en una sola operación indivisible. La documentación de PostgreSQL lo explica con una precisión difícil de mejorar: «el punto esencial de una transacción es que agrupa varios pasos en una única operación de todo o nada. Los estados intermedios entre los pasos no son visibles para otras transacciones concurrentes, y si ocurre alguna falla que impide completar la transacción, entonces ninguno de los pasos afecta a la base de datos».

El ejemplo canónico, y el que usa esa misma documentación, es una transferencia bancaria. Pasar dinero de una cuenta a otra son dos operaciones: descontar de una y acreditar en la otra. Si el sistema se cae entre las dos, el dinero desapareció.

> **Por qué esto no es un tema avanzado:** suele presentarse como algo para más adelante y es un error: cualquier operación que toque **dos tablas a la vez** necesita una transacción. Registrar una venta y descontar del stock. Crear un usuario y asignarle un rol. Si no están dentro de una transacción, el día que algo falle en el medio vas a tener datos inconsistentes que nadie sabe cómo arreglar.

Estas propiedades se resumen con la sigla **ACID**: atomicidad (todo o nada), consistencia (la base pasa de un estado válido a otro válido), aislamiento (las transacciones concurrentes no se ven entre sí a medias) y durabilidad (lo confirmado sobrevive a una caída). Es el vocabulario estándar y aparece siempre que se compara un motor con otro. La comparación con el enfoque alternativo, más laxo, está en [relacional vs no relacional](../relacional-vs-no-relacional/index.md).

## Qué tipos existen

Un panorama breve para ubicarte. La comparación en profundidad está en la última guía de esta serie.

| Tipo | Cómo organiza los datos | Ejemplos de motores |
|---|---|---|
| **Relacional** | Tablas con filas y columnas, vinculadas entre sí. Se consulta con SQL. | MySQL, PostgreSQL, SQL Server, Oracle, SQLite |
| **De documentos** | Documentos con estructura flexible, agrupados en colecciones. | MongoDB, CouchDB |
| **De clave y valor** | Un valor recuperable por su clave, sin estructura interna conocida. | Redis, Valkey |
| **De columnas anchas** | Filas con conjuntos de columnas variables, pensadas para volumen. | Cassandra, HBase |
| **De grafos** | Nodos y relaciones, donde el vínculo es tan importante como el dato. | Neo4j |

También existen modelos anteriores al relacional que siguen presentes sin que los llamemos así. La documentación de PostgreSQL lo señala con un ejemplo elegante: los **archivos y directorios** de un sistema Unix son un ejemplo de base de datos jerárquica.

> **Si no sabés qué elegir:** empezá por una relacional. Cubre la enorme mayoría de los casos, tiene el ecosistema más grande, el vocabulario más transferible entre trabajos y la mayor cantidad de material para aprender. Las alternativas resuelven problemas específicos, y conviene llegar a ellas sabiendo cuál es ese problema.

## Dónde hay bases de datos sin que se note

Vale la pena hacer este ejercicio porque cambia la percepción de «esto es algo de empresas grandes».

- **Tu teléfono.** Los contactos, los mensajes, el historial del navegador y los datos de casi cada aplicación viven en bases SQLite locales.
- **Cada sitio con cuenta de usuario.** El inicio de sesión consulta una base para verificar tus credenciales.
- **El sistema de tu médico, tu banco y tu obra social.** Con requisitos de integridad y auditoría bastante más estrictos.
- **Este portal.** El foro de Underc0de guarda cada hilo, mensaje y usuario en una base relacional.
- **Tu propio código.** El día que guardes algo que tenga que seguir existiendo después de cerrar el programa, ese es el momento.

## Cuándo conviene y cuándo no

Un criterio honesto, porque no todo necesita una base de datos y montar una donde no hace falta también es un error.

| Usá una base de datos si… | Un archivo o planilla alcanza si… |
|---|---|
| Más de una persona o proceso escribe | Sos la única persona que lo edita |
| Importa que los datos sean consistentes | Un error puntual no tiene consecuencias |
| Los datos van a crecer | El volumen es acotado y estable |
| Necesitás consultas y cruces | Solo necesitás leer o mirar la lista |
| Hay datos de personas o dinero | Son notas o cálculos personales |

Y una advertencia que corresponde en un portal de seguridad: **en el momento en que guardás datos de personas, asumís una responsabilidad**. No es solo cumplir con la normativa que aplique en tu jurisdicción; es entender que un descuido tiene consecuencias sobre gente real. Una base de datos ayuda —permisos por usuario, registros de auditoría, cifrado de la conexión— pero solo si se configura, y eso empieza el primer día. La guía de [MySQL](../mysql-instalacion-y-primeros-pasos/index.md) incluye los pasos mínimos.

## Confusiones frecuentes

- **Creer que «base de datos» y «SQL» son lo mismo.** SQL es el lenguaje con que se consultan las bases relacionales, no la base ni el motor.
- **Pensar que una base de datos es un archivo grande.** Es un sistema con reglas activas: rechaza operaciones inválidas mientras corre.
- **Usar Excel como base de datos multiusuario.** Funciona hasta que dos personas guardan a la vez, y entonces se pierde trabajo sin aviso.
- **Suponer que el motor decide todo.** La mayoría de los problemas de rendimiento y de datos sucios vienen del *diseño*, no del motor elegido.
- **Dejar las transacciones para después.** Cualquier operación que toque dos tablas ya las necesita.
- **Guardar datos personales sin pensarlo.** Recolectar de más es el error más difícil de revertir: lo que no guardás no se puede filtrar.

## Preguntas frecuentes

**¿Cuál es la diferencia entre una base de datos y una planilla?**
Una planilla guarda datos; una base de datos los guarda y además los protege. La diferencia concreta son cuatro cosas que una planilla no puede garantizar: que cada dato exista una sola vez, que no se pueda escribir un valor inválido en una columna, que varias personas escriban a la vez sin pisarse, y que una operación que toca varios registros se complete entera o no se complete. Con veinte filas y una sola persona la planilla alcanza. El límite aparece cuando los datos se comparten y crecen.

**¿Qué diferencia hay entre base de datos y motor de base de datos?**
La base de datos son los datos; el motor es el programa que los administra. En inglés al motor se lo llama DBMS, por database management system, o RDBMS cuando es relacional. MySQL, PostgreSQL y SQLite son motores; la base de datos es lo que vos creás dentro de ellos. La distinción importa en la práctica porque casi todo lo que uno aprende —permisos, respaldos, rendimiento, tipos de dato— es del motor, no de la base.

**¿Qué es una transacción?**
Es un conjunto de operaciones que se agrupan en una sola operación de todo o nada. La documentación de PostgreSQL lo explica así: los estados intermedios entre los pasos no son visibles para otras transacciones concurrentes, y si algo falla antes de terminar, ninguno de los pasos afecta a la base. El ejemplo clásico es una transferencia: descontar de una cuenta y acreditar en otra tienen que pasar juntos o no pasar. Sin transacciones, una falla en el medio deja dinero que desapareció.

**¿Necesito una base de datos para un proyecto chico?**
Depende de tres preguntas: ¿los datos los va a modificar más de una persona a la vez?, ¿importa que estén consistentes?, ¿van a crecer? Si la respuesta a las tres es no, un archivo o una planilla puede ser suficiente y más simple. Si alguna es sí, conviene una base desde el principio, porque migrar después siempre cuesta más. Para proyectos chicos existe SQLite, que es una base de datos completa guardada en un solo archivo, sin servidor que administrar.

**¿Qué tipos de base de datos existen?**
El grupo más usado son las relacionales, que guardan los datos en tablas vinculadas entre sí y se consultan con SQL: MySQL, PostgreSQL, SQL Server, Oracle, SQLite. Aparte están las llamadas no relacionales o NoSQL, que se dividen en cuatro familias: de documentos, de clave y valor, de columnas anchas y de grafos. También existen modelos más antiguos como el jerárquico, que la documentación de PostgreSQL ilustra con los archivos y directorios de un sistema Unix. Para la mayoría de los proyectos, una relacional es el punto de partida correcto.

**¿Hace falta saber programar para usar una base de datos?**
No para consultarla. SQL es un lenguaje de consultas, no un lenguaje de programación de propósito general, y sus instrucciones básicas se aprenden en un rato: se parecen más a escribir una frase en inglés que a programar. Mucha gente de perfil no técnico —analistas, marketing, contabilidad, QA— usa SQL a diario sin programar. Programar se vuelve necesario cuando querés construir una aplicación que use esa base.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.

1. **PostgreSQL.** [Concepts](https://www.postgresql.org/docs/current/tutorial-concepts.html). Definición de RDBMS, relación como término matemático para tabla, y el ejemplo de los archivos y directorios de Unix como base jerárquica.
2. **PostgreSQL.** [Transactions](https://www.postgresql.org/docs/current/tutorial-transactions.html). Definición de transacción como operación de todo o nada y el ejemplo de la transferencia bancaria.
3. **PostgreSQL.** [Constraints](https://www.postgresql.org/docs/current/ddl-constraints.html). Cómo las restricciones dan control sobre los datos y por qué los tipos de dato solos no alcanzan.
4. **Underc0de, foro.** [Sección Base de Datos](https://underc0de.org/foro/base-de-datos/). Espacio de la comunidad donde se comparte material sobre bases de datos desde 2012.

## Guías relacionadas

- [Bases de datos relacionales y tablas](../bases-de-datos-relacionales-y-tablas/index.md) — el siguiente paso de la ruta.
- [Introducción a SQL desde cero](../introduccion-a-sql-desde-cero/index.md)
- [Cómo diseñar una base de datos sencilla](../como-disenar-una-base-de-datos-sencilla/index.md)
- [MySQL: instalación y primeros pasos](../mysql-instalacion-y-primeros-pasos/index.md)
- [Base de datos relacional vs no relacional](../relacional-vs-no-relacional/index.md)
- [Guías de Datos y bases de datos](../index.md)

---

Esta guía forma parte de un proyecto de la comunidad Underc0de para organizar conocimiento técnico en español. Fuente canónica: https://underc0de.org/guias/bases-de-datos/que-es-una-base-de-datos/