Última actualización: 2026-10-24

Contenido de esta página

• ¿Cuáles son las características de una base de datos?
• Integridad, consistencia y redundancia controlada: que los datos cumplan sus reglas
• Acceso multiusuario, concurrencia y seguridad: muchas personas sobre los mismos datos
• Persistencia, recuperación y respaldo: que lo guardado no se pierda
• Independencia y escalabilidad: que la base aguante cambios y crecimiento
• ¿Cuál es la funcionalidad de una base de datos? Sus cuatro funciones
• Cualidades de la información en una base de datos
• Ventajas de una base de datos frente al archivo plano y la hoja de cálculo
• Desventajas de una base de datos: costo, complejidad, administración y riesgo
• ¿Cuántas de las diez características ha visto funcionar?

Historia real. La mañana del 11 de enero de 2023, la Administración Federal de Aviación de Estados Unidos, la FAA, ordenó a las aerolíneas detener todas las salidas de vuelos nacionales [1]. La pausa iba hasta las nueve de la mañana, hora del este [1]. Venía de una caída nocturna del sistema de avisos a las misiones aéreas, el NOTAM, que entrega información de seguridad a las tripulaciones de vuelo [1].

El problema no era el clima ni un avión. La agencia explicó que necesitaba ese tiempo para «validar la integridad de la información de vuelo y de seguridad» [1]. Las citas en inglés de esta página son traducción propia.

Al final de ese día, la FAA dijo que su trabajo preliminar había rastreado la caída hasta «un archivo de base de datos dañado» [1]. Ocho días después publicó la causa preliminar. Personal contratista había borrado archivos sin querer mientras corregía la sincronización entre la base de datos principal y una base de respaldo [1]. Hasta entonces, la agencia no había encontrado indicios de un ciberataque [1].

La FAA tenía una base principal y otra de respaldo, y aun así tuvo que frenar los despegues para revisar si sus datos eran confiables. De eso trata esta página. Las características de una base de datos no son adjetivos de folleto. Son garantías, y cada una se puede comprobar con una prueba antes de que haga falta.

¿Cuáles son las características de una base de datos?

Las características de una base de datos son las garantías que el sistema da sobre los datos que guarda. Son diez: integridad, consistencia, redundancia controlada, acceso multiusuario, concurrencia, seguridad y permisos, persistencia y recuperación, respaldo, independencia y escalabilidad. No todos los programas las ofrecen igual, así que conviene comprobarlas una por una.

Qué es una base de datos y para qué sirve se explica en la guía de bases de datos. Esta página se ocupa de otra pregunta: cómo saber si la suya cumple lo que promete.

La lista no es un invento de esta página. El curso de bases de datos de la Universidad de Cantabria, en España, enumera seis de ellas como ventajas de las bases relacionales [2]. Su lista incluye independencia física y lógica, control de la integridad, consistencia, acceso concurrente, protección ante fallos y seguridad [2]. SQLite es un motor de bases de datos gratuito. Su documentación resume en cuatro palabras lo que destacan los motores que atienden a muchos programas desde un servidor: escalabilidad, concurrencia, centralización y control [3].

Algunas se parecen, y el parecido no es descuido. La integridad y la consistencia hablan de reglas, pero una mira cada dato y la otra cada operación completa. La recuperación y el respaldo hablan de no perder nada, pero protegen de accidentes distintos. Las dos parejas se separan más abajo.

Las 10 características de una base de datos y cómo comprobarlas

Característica	Qué garantiza	Cómo comprobar si su sistema la cumple	Qué pasa si falta
1. Integridad	Ningún dato guardado viola las reglas que se declararon para él	Intente guardar un dato imposible, como un cupo negativo: el sistema debe rechazarlo con un error [4]	Los errores entran sin aviso y aparecen después, en un informe
2. Consistencia	Cada operación de varios pasos deja la base cumpliendo sus reglas	Provoque un error a mitad de una operación e intente confirmarla: ninguna regla declarada debe quedar rota [5]	Una operación partida se confirma y deja rota una regla declarada
3. Redundancia controlada	Las copias de un dato las crea y las mantiene el propio sistema	Pregunte, dato por dato, dónde está la versión oficial y quién actualiza las copias	Copias que se contradicen sin que nadie sepa cuál manda
4. Acceso multiusuario	Muchas personas y programas se conectan al mismo tiempo	Averigüe el tope de conexiones del servidor y compárelo con su hora de más trabajo [6]	Las conexiones de más se rechazan, o el archivo pasa de mano en mano
5. Concurrencia	Dos personas que cambian el mismo dato no se estorban	Haga la prueba de las dos ventanas que se describe más abajo [7]	Aparecen datos incoherentes cuando dos personas cambian lo mismo a la vez [2]
6. Seguridad y permisos	Cada usuario ve y hace solo lo que le corresponde	Entre con un usuario de solo consulta e intente borrar: debe recibir un error de permiso [8]	Cualquiera lee o cambia lo que no debe
7. Persistencia y recuperación	Lo confirmado sobrevive a un apagón y lo pendiente se descarta	Confirme un cambio, deje otro pendiente, corte el programa y vuelva a abrir [5]	Tras un corte de luz faltan datos confirmados o quedan cambios a medias
8. Respaldo	Existe una copia aparte para volver a un punto anterior	Restaure la copia en otro equipo y revísela [9]	Un borrado por error o un disco dañado se vuelven definitivos [9]
9. Independencia lógica y física	Cambiar cómo o qué se guarda no rompe los programas	Agregue un índice (la lista ordenada que acelera las búsquedas) o una columna: las consultas de siempre deben seguir funcionando [10]	Cada ajuste técnico obliga a reescribir programas e informes
10. Escalabilidad	La base aguanta más datos y más usuarios sin rehacerla	Mire cómo resuelve el gestor (el programa que administra la base) su consulta más usada y mídala con más datos [11]	Lo que hoy responde al instante se vuelve lento al crecer

Integridad, consistencia y redundancia controlada: que los datos cumplan sus reglas

Integridad, consistencia y redundancia controlada son las tres características que protegen el contenido de una base de datos. La integridad impide guardar un dato que viola una regla. La consistencia hace que cada operación de varios pasos deje la base cumpliendo sus reglas. La redundancia controlada acepta copias de un dato solo si el propio sistema las mantiene al día.

Integridad: el sistema rechaza lo que viola una regla

La integridad es la garantía de que ningún dato guardado contradice las reglas que se declararon para él. Esas reglas se llaman restricciones: que un valor no falte, que no se repita, que esté en un rango o que apunte a algo que existe. Su vocabulario completo está en fundamentos de bases de datos. Aquí interesa otra cosa: quién las hace cumplir.

PostgreSQL es un gestor libre (su código se puede leer y modificar) y gratuito, es decir, un programa que administra bases de datos. Su documentación es directa sobre las reglas: si alguien intenta guardar un dato que viola una restricción, el sistema produce un error [4]. Ahí está la diferencia con un archivo suelto, donde la regla depende de que cada programa que lo toca la recuerde [2].

Para comprobarla, tome una regla de su negocio e intente romperla a propósito, directamente en la base y no desde el formulario. Si el sistema acepta el dato imposible, para él la regla no existe.

Consistencia: en qué se diferencia de la integridad

La consistencia es la integridad vista sobre operaciones completas. PostgreSQL la define como la propiedad de que los datos cumplan siempre las restricciones [5]. Una transacción, es decir, un grupo de pasos que se ejecuta entero o no se ejecuta, puede romper algunas un instante. Si no lo corrige antes de confirmarse, se deshace sola [5].

El curso de Cantabria pregunta por las dos en un mismo ejercicio, pero por separado, y explica cómo se pierde la segunda: con actualizaciones parciales [2]. La integridad mira cada dato. La consistencia mira la operación entera.

La prueba de abajo usa SQLite, que guarda toda la base en un solo archivo, y la corrí en su versión 3.53.1. Un taller tiene un cupo libre. Las órdenes COMMIT (confirmar) y ROLLBACK (deshacer) cierran cada transacción.

-- Integridad: la regla se declara en la tabla, no en el formulario
CREATE TABLE taller (
  nombre       TEXT PRIMARY KEY,
  cupos_libres INTEGER NOT NULL CHECK (cupos_libres >= 0)
);
CREATE TABLE inscripcion (
  documento TEXT NOT NULL,
  taller    TEXT NOT NULL,
  PRIMARY KEY (documento, taller)
);
INSERT INTO taller VALUES ('Huerta casera', 1);

-- Prueba 1: un dato imposible no entra
UPDATE taller SET cupos_libres = -5 WHERE nombre = 'Huerta casera';
-- Falla: CHECK constraint failed: cupos_libres >= 0

-- Prueba 2: inscribir y descontar el cupo van juntos
BEGIN;
INSERT INTO inscripcion VALUES ('1001', 'Huerta casera');
UPDATE taller SET cupos_libres = cupos_libres - 1 WHERE nombre = 'Huerta casera';
COMMIT;

BEGIN;
INSERT INTO inscripcion VALUES ('1002', 'Huerta casera');
UPDATE taller SET cupos_libres = cupos_libres - 1 WHERE nombre = 'Huerta casera';
-- Falla: CHECK constraint failed: cupos_libres >= 0 (ya no hay cupo)
ROLLBACK;  -- deshace también la inscripción de 1002

SELECT documento FROM inscripcion;
-- 1001

La primera prueba es de integridad: el cupo negativo no entra. La segunda es de consistencia: la inscripción de 1002 falla a mitad de camino y ROLLBACK la deshace completa.

Un detalle de SQLite cambia la lectura. En este motor, el error anula solo la orden que falló, y las anteriores de la misma transacción siguen pendientes [12]. Lo comprobé cambiando ROLLBACK por COMMIT: la persona 1002 quedó inscrita sin cupo. Ninguna regla se violó, porque nadie había escrito que cada inscripción necesita un cupo.

La consistencia protege las reglas declaradas. Las que solo existen en la cabeza de alguien no las ve.

Redundancia controlada: copias, pero bajo control

Hay redundancia cuando un mismo dato vive en dos o más lugares. Cuando esa repetición queda en manos de las personas, produce contradicciones, y fundamentos de bases de datos explica las anomalías que deja. La redundancia controlada no prohíbe las copias. Exige que las cree y las mantenga el propio sistema.

Hay dos ejemplos comunes. Un índice, la lista ordenada que acelera las búsquedas, se mantiene solo: PostgreSQL lo actualiza cada vez que la tabla cambia [10]. Una réplica es una base emparejada con la principal, que guarda copia de sus datos para dar más acceso y seguir disponible si la principal falla [5].

Controlar las copias tiene un costo. La documentación de PostgreSQL llama a la sincronización entre servidores «la dificultad fundamental» de hacerlos trabajar juntos [13]. Según la revisión preliminar de la FAA, el daño ocurrió mientras personal contratista corregía la sincronización entre su base principal y una de respaldo [1].

Aquí no hace falta código. Haga una lista de sus datos importantes y escriba al lado dónde está la versión oficial de cada uno. Si para alguno la respuesta es «depende» o «en el correo de alguien», esa redundancia no está controlada.

Acceso multiusuario, concurrencia y seguridad: muchas personas sobre los mismos datos

Acceso multiusuario, concurrencia y seguridad son las características que entran en juego cuando varias personas usan la misma base de datos. El acceso multiusuario dice cuántas pueden conectarse a la vez. La concurrencia dice qué pasa cuando dos cambian el mismo dato. La seguridad decide quién puede ver o cambiar cada cosa.

Acceso multiusuario: cuántos pueden entrar a la vez

El acceso multiusuario es la capacidad de atender muchas conexiones al mismo tiempo, cada una con su propia sesión, es decir, su propio canal de trabajo. Tiene un tope, y conviene conocerlo. En PostgreSQL lo fija el parámetro max_connections, que por lo general viene en 100 conexiones [6]. Por encima de ese número, el servidor no admite conexiones activas nuevas [6].

SQLite trabaja distinto: admite lectores sin límite, pero un solo escritor en cada instante [3]. Para comprobar esta característica, busque el tope de su sistema y compárelo con cuántas personas y programas se conectan en la hora de más trabajo.

Concurrencia: en qué se diferencia del acceso multiusuario

La concurrencia es el control de lo que pasa cuando dos usuarios tocan el mismo dato al mismo tiempo. El acceso multiusuario dice cuántos entran; la concurrencia, cómo conviven. El curso de Cantabria lo ilustra con dos personas que actualizan la misma cuenta corriente: el sistema tiene que impedir que lo hagan a la vez [2].

PostgreSQL resuelve buena parte del problema guardando varias versiones de cada dato. Su documentación resume la ventaja así: «leer nunca bloquea escribir y escribir nunca bloquea leer» [14]. En su modo predeterminado, cada consulta ve solo los cambios que ya estaban confirmados cuando empezó [7].

La prueba de las dos ventanas sirve para cualquier gestor pensado para varios usuarios:

1. Abra dos sesiones sobre la misma base: la ventana A y la ventana B.
2. En la ventana A, empiece una transacción y cambie un dato, sin confirmar.
3. En la ventana B, lea ese dato. Debe ver el valor anterior, no el pendiente [7].
4. En la ventana B, intente cambiar el mismo dato. Debe esperar a que A termine o recibir un error de bloqueo [7].
5. Confirme en A y vuelva a leer en B. Ahora sí debe aparecer el valor nuevo.

La repetí en SQLite con dos conexiones. La ventana B leyó el valor anterior y, al intentar escribir, recibió el error «database is locked», es decir, base de datos bloqueada.

Seguridad y permisos: quién puede hacer qué

La seguridad de una base de datos es la garantía de que cada usuario entra con su identidad y solo hace lo que se le permitió. Primero el sistema confirma quién es; después revisa qué puede leer o cambiar [15]. En PostgreSQL, quien crea una tabla es normalmente su dueño. Al principio solo él, o un superusuario (una cuenta con todos los permisos), puede hacer algo con ella; los demás necesitan permisos otorgados [8].

Microsoft recomienda para SQL Server, su gestor comercial, el criterio del menor privilegio. Cada rol debe recibir los permisos mínimos que necesita la aplicación, y no más [15].

En Colombia, si la base guarda datos personales, esta característica deja de ser opcional. La ley de protección de datos exige medidas técnicas, humanas y administrativas para proteger los registros [16]. Deben evitar su adulteración, su pérdida y su consulta, uso o acceso no autorizado o fraudulento [16].

Comprobarla toma dos pasos. Primero, pida la lista de quién tiene qué permiso sobre cada tabla; la consola de PostgreSQL trae órdenes para mostrarla [8]. Después, entre con un usuario de solo consulta e intente borrar una fila: debe fallar. SQLite no sirve para esta prueba, porque no tiene permisos por usuario, solo los del sistema operativo sobre el archivo [17].

Persistencia, recuperación y respaldo: que lo guardado no se pierda

Persistencia, recuperación y respaldo son las características que protegen los datos frente a los fallos. La persistencia garantiza que un cambio confirmado sobreviva a un apagón. La recuperación es lo que hace el sistema al volver a arrancar para quedar en orden. El respaldo es una copia aparte que permite volver a un punto anterior cuando el daño ya quedó confirmado.

Persistencia y recuperación: lo confirmado sobrevive al apagón

La persistencia, que la documentación técnica llama durabilidad, garantiza que un cambio confirmado se conserve aunque después el sistema falle [5]. Su pareja es la atomicidad. Si el fallo llega en medio de una transacción, después de la recuperación no queda a la vista ningún resultado parcial [5].

Un método estándar es anotar antes de hacer. PostgreSQL escribe cada cambio en un registro antes de tocar los archivos de datos, y tras una caída rehace desde ese registro lo que faltaba [18]. La guía de gestores de bases de datos cuenta cómo lo hace SQL Server. Microsoft llama recuperación a la fase del arranque que devuelve la base a un estado coherente con sus transacciones [9].

Para la prueba, seguí con la base de los talleres. Simulé la caída terminando el programa a la fuerza, en medio de una transacción; no es un corte de luz real.

-- Sesión 1: una inscripción confirmada y otra pendiente
BEGIN;
INSERT INTO inscripcion VALUES ('1003', 'Huerta casera');
COMMIT;
BEGIN;
INSERT INTO inscripcion VALUES ('1004', 'Huerta casera');
-- Aquí el programa se corta a la fuerza, sin COMMIT

-- Sesión 2: se vuelve a abrir el mismo archivo
SELECT documento FROM inscripcion;
-- 1001
-- 1003

La 1003 sigue ahí porque se confirmó. La 1004 desapareció porque no alcanzó a confirmarse.

Respaldo: por qué no es lo mismo que la recuperación

El respaldo, o copia de seguridad, es una copia de los datos que se guarda aparte para restaurarlos después de un fallo [9]. La recuperación no lo reemplaza, por una razón sencilla: protege lo confirmado, y un error humano también se confirma. Si alguien borra una tabla por equivocación, el sistema conserva ese borrado con el mismo cuidado con que conservaría un pago [5].

Microsoft da ejemplos de los daños de los que protege un respaldo válido. Están las fallas del medio de almacenamiento, los errores de usuario como borrar una tabla, los daños del equipo y los desastres naturales [9]. También recomienda guardar copias en un lugar seguro, fuera de la sede [9].

Mecanismo	Qué hace	Le protege de	No le protege de
Recuperación al arrancar	Usa el registro de cambios para dejar la base en orden tras una caída [18]	Apagones y caídas del servidor	Un error humano que ya se confirmó
Réplica	Mantiene en otro servidor una copia que reproduce los cambios de la principal [5]	La caída de la máquina principal, porque otra puede tomar el relevo [13]	Un borrado confirmado, que la réplica también reproduce
Respaldo	Guarda aparte una copia de la base tal como estaba al terminar la copia [9]	Errores de usuario, discos dañados y desastres [9]	Los cambios hechos después de la última copia

El respaldo tiene su propia prueba. Microsoft la escribe en su guía de respaldo y restauración de SQL Server, actualizada en agosto de 2026: «No tiene una estrategia de restauración hasta que prueba sus respaldos» [9]. La guía pide restaurar una copia en un sistema de prueba y revisar la base restaurada [9].

En SQLite, la orden VACUUM INTO (compactar en otro archivo) copia una base en uso, como una foto coherente de su contenido [19]. La orden PRAGMA integrity_check (revisar la integridad), una de las órdenes especiales de SQLite, revisa la copia. Busca registros mal formados, páginas faltantes y violaciones de las reglas UNIQUE (no repetir), CHECK (cumplir una condición) y NOT NULL (no quedar vacío). Si no encuentra nada, responde «ok» [20].

-- Respaldo: una copia completa y coherente en otro archivo
VACUUM INTO 'respaldo-talleres.db';

-- La prueba que cuenta: abrir la copia y revisarla
-- (en otra sesión, sobre el archivo respaldo-talleres.db)
PRAGMA integrity_check;
-- ok
SELECT documento FROM inscripcion;
-- 1001
-- 1003

Independencia y escalabilidad: que la base aguante cambios y crecimiento

Independencia y escalabilidad son las características que miran al futuro de una base de datos. La independencia permite cambiar cómo o qué se guarda sin reescribir los programas que la usan. La escalabilidad permite atender más datos, más usuarios y más consultas sin rehacer el sistema. Las dos se comprueban con la misma pregunta: ¿qué se rompe cuando algo cambia o crece?

Independencia lógica y física: cambiar sin romper

La independencia física permite cambiar la forma de guardar los datos sin tocar los programas. La lógica permite cambiar la estructura sin tocar los programas ni las vistas, que son consultas guardadas con nombre. Las dos están definidas, con ejemplos, en fundamentos de bases de datos. Aquí van sus pruebas.

Para la física, agregue un índice. Las consultas no deben cambiar ni una letra, y el sistema debe empezar a usarlo por su cuenta. En PostgreSQL, una vez creado el índice, no hace falta ninguna otra intervención [10].

Para la lógica, agregue una columna a una tabla y vuelva a correr los informes de siempre: deben seguir funcionando. PostgreSQL recomienda, además, usar vistas con generosidad. Sirven para esconder detalles de la estructura de las tablas que pueden cambiar con el tiempo [21].

Escalabilidad: crecer sin rehacer

La escalabilidad es la capacidad de crecer sin rehacer el sistema. Se crece con una máquina más potente o repartiendo el trabajo entre varias, y las dos vías no cuestan lo mismo. Según la documentación de PostgreSQL, juntar servidores que solo leen es relativamente fácil, y juntar servidores que leen y escriben es mucho más difícil [13].

La prueba más útil no exige comprar nada. Antes de que los datos crezcan, mire cómo resuelve el gestor su consulta más frecuente. PostgreSQL arma un plan para cada consulta y lo muestra con la orden EXPLAIN (explicar) [11]. SQLite tiene su versión, EXPLAIN QUERY PLAN: SCAN significa que recorre la tabla entera, y SEARCH, que visita solo una parte [22].

-- 200.000 registros de asistencia de prueba, de 20.000 documentos
CREATE TABLE asistencia (
  documento TEXT NOT NULL,
  sesion    INTEGER NOT NULL,
  horas     INTEGER NOT NULL
);
WITH RECURSIVE n(i) AS (SELECT 1 UNION ALL SELECT i + 1 FROM n WHERE i < 200000)
INSERT INTO asistencia SELECT i % 20000 + 1, i / 20000, 2 FROM n;

-- La consulta de todos los días: ¿cómo la resuelve el gestor?
EXPLAIN QUERY PLAN
SELECT sum(horas) FROM asistencia WHERE documento = '4517';
-- SCAN asistencia  (recorre la tabla entera)

-- Cambio físico: un índice. La consulta no cambia ni una letra
CREATE INDEX idx_asistencia_documento ON asistencia (documento);

EXPLAIN QUERY PLAN
SELECT sum(horas) FROM asistencia WHERE documento = '4517';
-- SEARCH asistencia USING INDEX idx_asistencia_documento (documento=?)

El mismo ejemplo prueba la independencia física. La consulta quedó idéntica, y fue el gestor quien decidió usar el índice. En mi computador, con la base guardada en un archivo, la consulta pasó de unos 11 milisegundos (milésimas de segundo) a unos 0,16 milisegundos. Es la mediana de 5 rondas de 200 consultas.

El índice no es gratis. PostgreSQL advierte que el sistema debe mantenerlo sincronizado con la tabla, y eso agrega trabajo a cada cambio de datos [10]. En este caso se paga en cada escritura para ganar en cada búsqueda.

¿Cuál es la funcionalidad de una base de datos? Sus cuatro funciones

La funcionalidad de una base de datos se resume en cuatro verbos: almacenar, controlar, consultar y actualizar información. Así la presenta el curso de la Universidad de Cantabria, que pone dentro de «controlar» las restricciones y la seguridad [2]. Las diez características sirven para comprobar que esas cuatro funciones se cumplen de verdad, más allá de lo que promete el programa.

Almacenar se comprueba con la persistencia, el respaldo y la redundancia controlada. Controlar, con la integridad, la consistencia y los permisos. Consultar, con el acceso multiusuario y la escalabilidad. Actualizar, con la concurrencia y la independencia. Qué pieza del programa se encarga de cada función está en la guía de gestores de bases de datos. Cómo se ven esas funciones en sistemas reales, del cajero automático al censo electoral, se cuenta en ejemplos de bases de datos.

Cualidades de la información en una base de datos

Las cualidades de la información son propiedades del dato, no del sistema que lo guarda. La ley colombiana de protección de datos personales las exige a los datos personales que se tratan: la información debe ser veraz, completa, exacta, actualizada, comprobable y comprensible [16]. Una base de datos puede cumplir sus diez características y aun así guardar un teléfono equivocado.

Distinguirlas importa porque cada una se arregla con herramientas distintas. Una restricción puede exigir que un número de celular tenga diez dígitos, pero no puede saber si es el de la persona. Eso lo resuelve un proceso: quién captura, quién verifica y cada cuánto se actualiza.

La misma ley separa los dos asuntos en principios distintos: uno de veracidad o calidad y otro de seguridad [16]. Quién responde por la calidad del dato dentro de una organización es tema de gobierno de datos.

Ventajas de una base de datos frente al archivo plano y la hoja de cálculo

La principal ventaja de una base de datos frente a un archivo plano es que el sistema pone las reglas, los permisos y la coordinación entre usuarios. Ya no dependen de cada programa ni de cada persona. Un archivo plano es un archivo de texto con los datos en filas, como un CSV, que separa los valores con comas. Sirve en aplicaciones sencillas cuya estructura casi no cambia, o cuando no hay varios usuarios [2]. Por qué se pasó del archivo plano al gestor se cuenta en qué es una base de datos.

Las bases de datos cliente/servidor son las que atienden, desde un servidor central, a muchos programas que se conectan a él. La documentación de SQLite marca la frontera así: «SQLite no compite con las bases de datos cliente/servidor. SQLite compite con fopen()» [3]. La función fopen() es la que usa un programa escrito en lenguaje C para abrir un archivo común. Es decir, un motor como SQLite no viene a reemplazar al gran servidor: viene a reemplazar al archivo suelto.

Forma de guardar	Reglas sobre los datos	Varias personas a la vez	Cómo se consulta	Para qué sirve mejor
Archivo plano	Las escribe cada programa que lo usa, en su propio código [2]	Coordinar el acceso simultáneo exige mucho código propio, que atrae errores [23]	Hace falta un programa para cada pregunta [2]	Aplicaciones sencillas con estructura estable, o de un solo usuario [2]
Hoja de cálculo	Controla lo que se teclea con Validación de datos, pero no admite integridad referencial [24]	En una carpeta de red compartida, solo una persona edita el libro a la vez [24]	Fórmulas y tablas dinámicas [24]	Analizar y calcular [24]
Base de datos	El gestor las hace cumplir y rechaza lo que las viola [4]	Muchos leen y escriben a la vez, con control de concurrencia [14]	Se pide qué se quiere y el motor decide cómo buscarlo [23]	Datos que comparten y cambian muchas personas [3]

Hay una ventaja que la tabla no muestra: los cambios de todo o nada. SQLite la pone como argumento para preferir una base de datos a un formato de archivo propio. Sus escrituras ocurren completas o no ocurren, aun si se cae el sistema o se va la luz [23].

La integridad referencial de la tabla es la regla de que cada registro apunte a algo que existe, como un pedido a un cliente. Cuándo una hoja de Excel deja de bastar se explica en base de datos en Excel. Las ventajas propias del modelo de tablas relacionadas están en bases de datos relacionales.

Desventajas de una base de datos: costo, complejidad, administración y riesgo

Las desventajas de una base de datos son cuatro. Cuesta tiempo y a veces licencias, exige diseño previo, pide administración permanente y concentra el riesgo en un solo sistema. Cuando varias personas comparten los datos, esos costos compran las diez garantías. Cuando basta una lista de una sola persona, compran poco.

La administración es la que más se subestima. La documentación de PostgreSQL advierte que, como cualquier software de bases de datos, necesita tareas periódicas para rendir bien [25]. Esas tareas son obligatorias, y programarlas y vigilar que se ejecuten es responsabilidad del administrador [25]. SQLite está en el otro extremo: no necesita administración, y por eso sirve en aparatos que funcionan sin un experto al lado [3].

El diseño previo también cuesta. Hay que decidir tablas, reglas y permisos antes de que llegue el primer dato, y cada índice agrega trabajo a cada escritura [10]. Una hoja de cálculo deja empezar sin ese plano.

El costo de las licencias va de cero a precios por procesador, según el gestor, y la comparación está en la guía de gestores de bases de datos. El costo que no figura en ninguna lista de precios es el tiempo de quien diseña y vigila la base.

Y concentrar los datos concentra el riesgo. Si el sistema central falla, fallan a la vez todos los que dependen de él. A la FAA, un archivo de base de datos dañado, según su revisión preliminar, le tumbó el sistema de avisos y la llevó a frenar los despegues nacionales [1].

¿Cuántas de las diez características ha visto funcionar?

Si tuviera que quedarme con una sola de las diez, escogería el respaldo probado. Lo digo como practicante, no como regla: es la única de las diez que deshace un error que ya se confirmó. La integridad no distingue un borrado legítimo de uno equivocado. La persistencia lo conserva. La réplica lo copia.

Las pruebas de esta página no cuestan licencias. La mayoría caben en una tarde, con un motor gratuito y una copia de los datos. En una alcaldía pequeña o en una pyme de Bucaramanga, eso cambia quién puede saber si sus datos son confiables. Deja de depender de un proveedor que lo certifique y pasa a depender de alguien que haga las pruebas.

La FAA tuvo que frenar las salidas de vuelos nacionales de todo un país para validar la integridad de su información de vuelo. La pregunta para usted no es si su sistema tiene estas características. Es cuántas de ellas ha visto funcionar con sus propios ojos.

Preguntas frecuentes

¿Qué diferencia hay entre una característica y una ventaja de una base de datos? Una característica es algo que el sistema garantiza, como la integridad o el respaldo. Una ventaja es lo que usted gana con esa garantía frente a otra forma de guardar los datos. Que el gestor rechace un cupo negativo es una característica; no tener que revisar a mano cada planilla es la ventaja. Por eso una misma característica pesa mucho en un hospital y casi nada en una lista personal.

¿Qué tienen que ver las propiedades ACID con estas características? ACID es la sigla en inglés de atomicidad, consistencia, aislamiento y durabilidad, cuatro propiedades de las transacciones [5]. Tres de las diez características descansan en ellas: la consistencia; la concurrencia, que se apoya en el aislamiento [14]; y la persistencia y recuperación, que reúne durabilidad y atomicidad. Las otras siete van más allá de una transacción. El glosario de ciencia de datos define cada letra.

¿Todas las bases de datos cumplen las 10 características? No, y no por un defecto. SQLite admite un solo escritor a la vez [3] y no tiene permisos por usuario: solo aplica los del sistema operativo sobre el archivo [17]. Está pensado para guardar los datos de una aplicación o de un aparato, no los de una organización entera [3]. La pregunta útil no es si un motor «es» una base de datos, sino cuáles de las diez necesita su caso.

¿Cada cuánto hay que hacer una copia de seguridad? Depende de cuánto trabajo puede perder sin que duela. La documentación de PostgreSQL pide respaldar con regularidad [26]. Microsoft explica que una buena estrategia equilibra la menor pérdida de datos posible con el costo de guardar las copias [9]. Si perder un día de registros es inaceptable, un respaldo semanal no alcanza, y cualquier copia vale solo después de haberla restaurado con éxito.

¿Una base de datos pequeña necesita las 10 características? No todas con la misma urgencia. Una base que usa una sola persona en su computador puede vivir sin permisos por usuario ni control de muchas conexiones, porque nadie más entra. La integridad y el respaldo, en cambio, protegen de errores de captura y de borrados por descuido, que ocurren en bases de cualquier tamaño.

Referencias

1. Federal Aviation Administration (FAA), Departamento de Transporte de Estados Unidos. FAA NOTAM Statement, comunicados del 11 de enero de 2023 (7:15 a. m., 8:50 a. m. y 6:30 p. m., hora del este) y del 19 de enero de 2023 — la agencia ordenó pausar todas las salidas de vuelos nacionales hasta las 9 a. m., hora del este, «to allow the agency to validate the integrity of flight and safety information»; caída nocturna del sistema NOTAM, «that provides safety information to flight crews»; el trabajo preliminar rastreó la caída a «a damaged database file»; según la revisión preliminar, personal contratista borró archivos sin querer «while working to correct synchronization between the live primary database and a backup database»; hasta entonces, sin evidencia de ciberataque ni de intención maliciosa. FAA: NOTAM Statement — Consultada: 2026-10-24.
2. Zorrilla Pantaleón, Marta Elena y Duque Medina, Rafael. Tema 01. Introducción a las BD relacionales, curso Bases de Datos, OCW Universidad de Cantabria, 2011, licencia Creative Commons BY-NC-SA 3.0 — desventajas de los sistemas de ficheros (redundancia e inconsistencia, restricciones escritas en el código del programa, un programa para cada proceso, pérdida de consistencia por actualizaciones parciales, acceso concurrente que debe controlarse para evitar inconsistencias, como dos personas actualizando la misma cuenta corriente, y problemas de seguridad); ventajas de las técnicas de bases de datos relacionales (independencia física y lógica, control de la integridad, garantía de consistencia, facilidad de acceso concurrente, protección ante fallos del sistema y seguridad ante accesos restringidos); cuándo usar ficheros (aplicaciones sencillas con esquema que difícilmente cambie, restricciones de tiempo real o sin acceso multiusuario); las bases de datos sirven para almacenar, controlar (restricciones y seguridad), consultar y actualizar información; pregunta de repaso sobre integridad y consistencia y cómo se pierde la consistencia. Universidad de Cantabria: Tema 1, introducción a las bases de datos (PDF) — Consultada: 2026-10-24.
3. SQLite. Appropriate Uses For SQLite (página actualizada el 31 de mayo de 2025) — los motores cliente/servidor buscan un repositorio compartido de datos y enfatizan «scalability, concurrency, centralization, and control»; SQLite busca almacenamiento local para aplicaciones y dispositivos individuales; «SQLite does not compete with client/server databases. SQLite competes with fopen()»; una base SQLite no requiere administración y funciona en dispositivos sin soporte experto; admite lectores simultáneos sin límite, pero un solo escritor en cada instante. SQLite: Appropriate Uses For SQLite — Consultada: 2026-10-24.
4. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 5.5 «Constraints» — SQL permite definir restricciones sobre columnas y tablas; si un usuario intenta guardar en una columna datos que violan una restricción, se produce un error. PostgreSQL: Documentation 18, Constraints — Consultada: 2026-10-24.
5. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, apéndice M «Glossary» — ACID; atomicidad: las operaciones de una transacción se completan como una unidad o ninguna, y tras una falla no quedan resultados parciales visibles después de la recuperación; consistencia: los datos cumplen siempre las restricciones de integridad, y la transacción que no resuelve una violación al confirmarse se deshace automáticamente; durabilidad: los cambios confirmados permanecen tras una falla o caída del sistema; réplica: base emparejada con la principal que mantiene copia de sus datos para dar más acceso y mantener la disponibilidad si la principal deja de estar disponible; replicación: reproducción de los datos de un servidor en otro, en la física copiando tal cual todos los cambios de archivos. PostgreSQL: Documentation 18, Glossary — Consultada: 2026-10-24.
6. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 19.3 «Connections and Authentication» — max_connections fija el número máximo de conexiones simultáneas; el valor predeterminado suele ser de 100, pero puede ser menor; como máximo pueden estar activas a la vez max_connections conexiones. PostgreSQL: Documentation 18, Connections and Authentication — Consultada: 2026-10-24.
7. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 13.2 «Transaction Isolation» — Read Committed es el nivel predeterminado; una consulta solo ve datos confirmados antes de empezar y nunca datos sin confirmar; quien intenta actualizar una fila que otra transacción en curso ya cambió espera a que esa transacción confirme o deshaga. PostgreSQL: Documentation 18, Transaction Isolation — Consultada: 2026-10-24.
8. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 5.8 «Privileges» — al crear un objeto se le asigna un dueño; al principio solo el dueño (o un superusuario) puede hacer algo con él; para que otros roles lo usen hay que otorgarles privilegios; la consola psql tiene órdenes para examinar los privilegios de cada tipo de objeto. PostgreSQL: Documentation 18, Privileges — Consultada: 2026-10-24.
9. Microsoft. Back up and restore SQL Server databases (página fechada el 27 de agosto de 2026) — respaldar con regularidad reduce el riesgo de pérdida catastrófica; con respaldos válidos se recuperan datos tras fallas del medio, errores de usuario como borrar una tabla por error, fallas de hardware y desastres naturales; guardar copias en un lugar seguro fuera de la sede; glosario: un respaldo es una copia de los datos para restaurarlos y recuperarlos tras una falla; el respaldo completo representa la base al momento en que terminó; recovery es la fase del arranque o de la restauración que lleva la base a un estado consistente con sus transacciones; la estrategia equilibra mínima pérdida de datos y costo de mantener las copias; «You don’t have a restore strategy until you test your backups»; restaurar una copia en un sistema de prueba y revisar la base restaurada. Microsoft Learn: Back up and restore SQL Server databases — Consultada: 2026-10-24.
10. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 11.1 «Introduction» (índices) — una vez creado el índice no hace falta más intervención: el sistema lo actualiza cuando la tabla cambia y lo usa cuando lo considera más eficiente; mantenerlo sincronizado con la tabla agrega trabajo a las operaciones que modifican datos. PostgreSQL: Documentation 18, Indexes — Consultada: 2026-10-24.
11. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 14.1 «Using EXPLAIN» — PostgreSQL elabora un plan para cada consulta que recibe, y la orden EXPLAIN muestra el plan que crea el planificador. PostgreSQL: Documentation 18, Using EXPLAIN — Consultada: 2026-10-24.
12. SQLite. The ON CONFLICT Clause (página actualizada el 22 de noviembre de 2025) — ABORT es el algoritmo predeterminado: anula la sentencia que viola la restricción y deshace sus cambios, pero los cambios de sentencias anteriores de la misma transacción se conservan y la transacción sigue activa. SQLite: The ON CONFLICT Clause — Consultada: 2026-10-24.
13. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, capítulo 26 «High Availability, Load Balancing, and Replication» — varios servidores pueden trabajar juntos para que un segundo tome el relevo si falla el principal o para que varios sirvan los mismos datos; los servidores de solo lectura se combinan con relativa facilidad y los de lectura y escritura son mucho más difíciles de combinar; «This synchronization problem is the fundamental difficulty for servers working together». PostgreSQL: Documentation 18, High Availability, Load Balancing, and Replication — Consultada: 2026-10-24.
14. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 13.1 «Introduction» (control de concurrencia) — modelo multiversión: cada sentencia ve una foto de los datos, lo que da aislamiento a cada sesión y un rendimiento razonable en entornos multiusuario; «reading never blocks writing and writing never blocks reading». PostgreSQL: Documentation 18, Concurrency Control — Consultada: 2026-10-24.
15. Microsoft. SQL Server security best practices (aplica a SQL Server, Azure SQL Database y Azure SQL Managed Instance; página fechada el 7 de mayo de 2026) — los inicios de sesión se autentican y después se conceden permisos a usuarios y roles; usar estrategias de seguridad basadas en roles con el menor privilegio; los roles deben recibir los permisos mínimos que requiere la aplicación. Microsoft Learn: SQL Server security best practices — Consultada: 2026-10-24.
16. Congreso de la República de Colombia. Ley Estatutaria 1581 de 2012, por la cual se dictan disposiciones generales para la protección de datos personales — art. 4, literal d, principio de veracidad o calidad: la información sujeta a tratamiento «debe ser veraz, completa, exacta, actualizada, comprobable y comprensible»; literal g, principio de seguridad: medidas técnicas, humanas y administrativas para otorgar seguridad a los registros «evitando su adulteración, pérdida, consulta, uso o acceso no autorizado o fraudulento». Función Pública: Ley 1581 de 2012 — Consultada: 2026-10-24.
17. SQLite. SQL Features That SQLite Does Not Implement (página actualizada el 18 de abril de 2022) — GRANT y REVOKE no están implementados; como SQLite lee y escribe un archivo común, solo aplican los permisos normales del sistema operativo sobre ese archivo. SQLite: funciones de SQL que no implementa — Consultada: 2026-10-24.
18. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 28.3 «Write-Ahead Logging (WAL)» — método estándar para garantizar la integridad de los datos: los cambios a los archivos de datos se escriben solo después de quedar registrados; tras una caída, la base se recupera con el registro, rehaciendo los cambios que no se habían aplicado. PostgreSQL: Documentation 18, Write-Ahead Logging — Consultada: 2026-10-24.
19. SQLite. VACUUM (página actualizada el 12 de julio de 2025) — con la cláusula INTO, la base original no cambia y se crea una nueva en otro archivo; es una alternativa a la interfaz de respaldo para copiar una base en uso; la copia es una foto consistente de la base original. SQLite: VACUUM — Consultada: 2026-10-24.
20. SQLite. Pragma statements supported by SQLite, apartado PRAGMA integrity_check (página actualizada el 4 de octubre de 2026) — revisión de formato y consistencia que busca entradas fuera de orden, registros mal formados, páginas faltantes y errores de restricciones UNIQUE, CHECK y NOT NULL; si no encuentra errores, devuelve una sola fila con el valor «ok». SQLite: PRAGMA integrity_check — Consultada: 2026-10-24.
21. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 3.2 «Views» — usar vistas con generosidad es parte del buen diseño; permiten encapsular los detalles de la estructura de las tablas, que pueden cambiar con la aplicación, detrás de interfaces consistentes. PostgreSQL: Documentation 18, Views — Consultada: 2026-10-24.
22. SQLite. EXPLAIN QUERY PLAN (página actualizada el 31 de mayo de 2025) — «SCAN» indica un recorrido completo de la tabla y «SEARCH», que solo se visita un subconjunto de sus filas; si se usa un índice, el registro lo nombra; la salida sirve para depurar y su formato puede cambiar entre versiones. SQLite: EXPLAIN QUERY PLAN — Consultada: 2026-10-24.
23. SQLite. SQLite As An Application File Format — una base SQLite como formato de archivo frente a formatos propios o montones de archivos: lenguaje de consulta de alto nivel en el que se expresa «qué» información se quiere y el motor decide «cómo» obtenerla; escrituras atómicas que ocurren completas o no ocurren, aun con caídas del sistema o cortes de energía; acceso concurrente coordinado, mientras que en un formato propio la concurrencia exige mucho soporte en la aplicación y esa lógica «is a notorious bug-magnet». SQLite: SQLite As An Application File Format — Consultada: 2026-10-24.
24. Microsoft. Usar Access o Excel para administrar los datos (se aplica a Excel y Access para Microsoft 365, 2024 y 2021; página fechada el 29 de julio de 2026) — como Excel no admite datos relacionales, no puede admitir la integridad referencial; el comando Validación de datos controla la entrada; en una carpeta de red compartida, solo un usuario puede editar el libro a la vez; Excel está optimizado para el análisis y el cálculo de datos, con fórmulas y tablas dinámicas. Microsoft: usar Access o Excel para administrar los datos — Consultada: 2026-10-24.
25. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, capítulo 24 «Routine Database Maintenance Tasks» — como cualquier software de bases de datos, PostgreSQL requiere tareas periódicas para un rendimiento óptimo; son obligatorias y repetitivas; es responsabilidad del administrador configurar los scripts y comprobar que se ejecuten con éxito. PostgreSQL: Documentation 18, Routine Database Maintenance Tasks — Consultada: 2026-10-24.
26. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, capítulo 25 «Backup and Restore» — como todo lo que contiene datos valiosos, las bases de PostgreSQL deben respaldarse con regularidad; hay tres enfoques: volcado SQL, copia a nivel de sistema de archivos y archivado continuo. PostgreSQL: Documentation 18, Backup and Restore — Consultada: 2026-10-24.

Cómo investigamos esta página

• Pregunta que responde: Qué diez características definen una base de datos, cómo se comprueba cada una y qué ventajas y desventajas tiene frente a un archivo o una hoja de cálculo.
• Fuentes: identificadas 34 → incluidas 26
• Criterios de inclusión: documentación oficial de PostgreSQL, SQLite y Microsoft, la ley colombiana de datos personales, un curso universitario y un comunicado oficial; nada de blogs ni enciclopedias.
• Fecha de corte de los datos: 2026-10-24