En 09-01 vimos qué leer y en 09-02 dónde estudiar y practicar. Falta el tercer vértice, y es el que convierte lo demás en trabajo real: con qué. Esta lección es el inventario de herramientas con las que se trabaja de verdad con bases de datos —motores en tu propia máquina, clientes, diseño, migraciones, datos de prueba, diagnóstico y copias— y, sobre todo, el criterio de cuáles necesitas ya y cuáles no necesitas todavía.

Porque el error dominante en esta materia no es usar pocas herramientas, es acumularlas. Es fácil terminar con tres clientes gráficos instalados, dos herramientas de diagramas, un gestor de migraciones que no se usa y ninguna copia de seguridad configurada. El apartado final propone un kit mínimo de cinco piezas con el que se puede empezar mañana, y una lista explícita de lo que puedes ignorar sin remordimiento.

Todo lo que hay aquí está orientado a que puedas hacer lo que la última lección del módulo 8 te pedía: coger uno de los casos de VallBici o el esquema de BiblioRed, montarlo en tu máquina y romperlo.

Advertencia importante. Las versiones de los motores y de las herramientas avanzan constantemente; las opciones de línea de órdenes cambian; y las licencias y los modelos de negocio de las herramientas también cambian —hay proyectos que han pasado de libres a comerciales y al revés—. Los comandos de esta lección son correctos en su forma general, pero comprueba siempre la sintaxis y los nombres de paquete en la documentación de tu versión. Y la regla que gobierna todo lo demás: la documentación oficial manda sobre lo que diga cualquier curso, incluido este. Tampoco se cita ningún precio ni ninguna condición de plan gratuito, porque cambian sin aviso: verifica en la fuente oficial antes de contratar nada.

1. Motores en tu máquina: instalación y arranque
2. Docker y Docker Compose: el entorno de 08-03 en un comando
3. Bases de datos gestionadas en la nube
4. Clientes de consola: psql y mongosh
5. Clientes gráficos
6. Diseño y diagramas
7. Migraciones y control de versiones del esquema
8. Datos de prueba
9. Rendimiento y diagnóstico
10. Copias de seguridad, monitorización y administración
11. El kit mínimo
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión: el cierre del curso

Tener el motor instalado localmente no es negociable. Puedes aprender mucho contra una base de datos gestionada, pero no puedes apagarla a mitad de una transacción para ver qué pasa, y ese tipo de experimento es exactamente lo que te falta.

Tras la instalación en Linux existe el usuario del sistema postgres, que es el superusuario del motor. El primer paso razonable es crear tu propio rol y tu propia base de datos, en vez de trabajar siempre como superusuario —justo lo que se argumentó en 06-04:

El paquete postgresql-contrib merece una nota: trae extensiones que vas a querer, entre ellas pg_stat_statements (apartado 9), pg_trgm (búsqueda por similitud, la que se comparó con Elasticsearch en 08-03) y btree_gist (necesaria para las restricciones de exclusión sobre rangos).

SQLite es la herramienta más infravalorada del inventario. Para probar una idea de esquema, para analizar un CSV con SQL o para llevar datos de ejemplo en un repositorio, no hay nada más rápido. Recuerda lo de 01-02: su tipado es dinámico y su modelo de concurrencia es de un único escritor, así que no es un sustituto de PostgreSQL para una aplicación con varios usuarios escribiendo a la vez.

Para MongoDB y Redis, y aún más para Elasticsearch, la vía recomendable en una máquina de trabajo no es instalarlos como servicios del sistema, sino levantarlos con contenedores. Es lo que viene a continuación.

Instalar cuatro motores como servicios del sistema significa cuatro servicios arrancando siempre, cuatro configuraciones que mantener y una desinstalación penosa el día que quieras limpiar. Con contenedores, todo el entorno es un fichero de texto que puedes versionar, compartir y destruir sin dejar rastro.

Y este es el fichero que levanta el entorno del caso políglota de 08-03: PostgreSQL como fuente de la verdad transaccional, MongoDB para telemetría y fichas, y Redis para la disponibilidad en tiempo real.

Cuatro detalles del fichero que merecen atención, porque son los que separan un compose de juguete de uno útil:

1. Versión fijada (postgres:16, no postgres:latest). Con latest, un día actualizas la imagen sin querer y el formato de datos deja de ser compatible.
2. Volúmenes con nombre. Sin ellos, docker compose down se lleva tus datos por delante. Con ellos, sobreviven hasta que pidas explícitamente -v.
3. docker-entrypoint-initdb.d. Cualquier .sql que dejes en ./sql se ejecuta al crear la base de datos por primera vez. Es el sitio natural del esquema de BiblioRed o de VallBici: clonar el repositorio y docker compose up -d te deja el esquema creado.
4. healthcheck. Permite que tu aplicación —o un contenedor de migraciones— espere a que PostgreSQL esté realmente aceptando conexiones, no solo arrancado.

Si además quieres Elasticsearch para reproducir la búsqueda de estaciones, añádelo como un servicio más; ten en cuenta que consume bastante más memoria que los otros tres juntos y que suele necesitar ajustes de memoria de la máquina anfitriona.

Una base de datos gestionada es el mismo motor, operado por otro: copias de seguridad, actualizaciones, alta disponibilidad y monitorización vienen incluidas. Para aprender no las necesitas; para publicar un proyecto propio son muy cómodas.

Sobre las capas gratuitas. Varias de estas ofertas tienen capa gratuita o crédito inicial, y son perfectamente adecuadas para un proyecto de aprendizaje publicado. Pero las condiciones —límites de almacenamiento, pausas por inactividad, caducidad— cambian con frecuencia, así que consúltalas en la web oficial del proveedor en el momento en que vayas a usarlas. Y dos cautelas prácticas: primera, activa siempre las alertas de gasto antes de crear nada, porque el modo de facturación por uso puede sorprenderte; segunda, una base de datos gestionada no te exime de saber administrar: si no entiendes qué es un VACUUM o qué implica el nivel de aislamiento, el panel bonito no te va a salvar.

Empezamos por los clientes de consola y no por los gráficos deliberadamente. psql no es la opción básica: es la herramienta más potente de todas las que aparecen en esta lección. Todo lo que existe en un cliente gráfico existe en psql, y bastante de lo que hay en psql no existe en ningún cliente gráfico. Además está siempre disponible: en el servidor, dentro del contenedor, por SSH, en un script.

Retoman lo que en 01-04 se llamó el catálogo del sistema: cada uno de estos metacomandos es, en realidad, una consulta al catálogo escrita por ti sin darte cuenta.

Dos costumbres que valen mucho y cuestan poco: activar \timing siempre, para que cada consulta te diga lo que tarda; y usar \watch para observar en vivo un contador mientras otra sesión trabaja —es la forma más directa de ver los fenómenos de concurrencia de 06-02 sin ninguna herramienta adicional.

Un fichero ~/.psqlrc con tus preferencias hace el resto:

Ese \pset null '(null)' es más útil de lo que parece: por defecto un NULL y una cadena vacía se ven exactamente igual en la salida, y esa confusión ha costado muchas horas de depuración a mucha gente.

mongosh es un intérprete de JavaScript completo, no solo un cliente. Puedes escribir bucles, funciones y cargar ficheros con load('script.js'), lo que lo convierte en la herramienta natural para generar datos de prueba o para migraciones puntuales de documentos.

Un cliente gráfico aporta tres cosas reales: navegar un esquema desconocido mucho más rápido, ver los resultados en una rejilla cómoda y generar diagramas por ingeniería inversa. No aporta —y conviene no engañarse— ninguna capacidad que no tenga la consola.

Recomendación honesta. Instala uno. Si tocas varios motores, DBeaver. Si solo PostgreSQL y haces administración, pgAdmin. Si trabajas con MongoDB, Compass además del anterior porque hace cosas que ningún otro hace. Tener tres clientes relacionales instalados es una señal casi infalible de que no se ha aprendido bien ninguno.

Y una advertencia que se repite en el tiempo: las licencias de las herramientas cambian. Proyectos que empezaron libres han pasado a modelos comerciales y algunos al revés. Comprueba la licencia vigente antes de apoyar un flujo de trabajo de equipo en una herramienta concreta.

En 04-02 dibujaste diagramas entidad-relación y en 04-03 los transformaste en esquemas. Estas son las herramientas con las que eso se hace fuera de un curso.

El criterio. Para un diagrama que debe vivir en el tiempo —en el repositorio, revisado en cada cambio— usa Mermaid: es texto, se versiona y se lee en el README. Para un boceto de una tarde, dbdiagram.io. Para entender un esquema ajeno de sesenta tablas, ingeniería inversa con DBeaver o SchemaSpy y a partir de ahí decides.

Este es el erDiagram de Mermaid con el que puedes empezar a documentar tu propio esquema; es exactamente el formato que has visto durante todo el curso:

Guarda ese bloque en el README.md de tu proyecto y actualízalo en la misma confirmación en la que cambies el esquema. Es la aplicación literal del "documentar y versionar el esquema" de 04-01, y cuesta dos minutos.

Este apartado es el más importante de la lección, y el que más gente se salta.

En 04-01 se dijo que el esquema hay que documentarlo y versionarlo. Una migración es la forma profesional de hacerlo: cada cambio del esquema es un fichero, numerado y guardado en el repositorio junto al código, que se aplica en orden y del que la base de datos lleva registro. La consecuencia es que el esquema deja de ser el resultado de una serie de ALTER TABLE sueltos en la consola de alguien y pasa a ser una secuencia reproducible.

Por qué esto no es opcional. Cuatro razones, todas comprobables el primer día que trabajas en equipo:

1. Reproducibilidad. Cualquiera clona el repositorio, ejecuta las migraciones y obtiene exactamente tu esquema. Sin migraciones, "montar el entorno" es preguntar a un compañero.
2. El esquema y el código viajan juntos. La confirmación que añade la columna fecha_devolucion_real contiene también el código que la usa. Volver atrás una versión revierte las dos cosas.
3. Repetibilidad entre entornos. Lo que se aplicó en desarrollo se aplica idéntico en preproducción y en producción, sin que nadie escriba nada a mano bajo presión.
4. Historia y auditoría. «¿Cuándo se añadió este índice y por qué?» tiene respuesta: la confirmación, su fecha y su mensaje.

Cómo elegir. Si tu marco de trabajo ya trae migraciones, usa esas y punto. Si no usas marco, o quieres SQL explícito y controlado, Flyway o una herramienta ligera equivalente. Liquibase compensa en entornos con varios motores distintos y necesidad de reversión formal.

Un ejemplo mínimo con el formato de ficheros SQL numerados, aplicado a BiblioRed:

Tres reglas de oro sobre migraciones, aprendidas todas por las malas:

1. Una migración aplicada no se modifica jamás. Si estaba mal, se corrige con una migración nueva. Cambiar un fichero ya aplicado rompe la suma de verificación de la herramienta y desincroniza los entornos.
2. Toda migración debe poder ejecutarse sobre datos reales. Añadir una columna NOT NULL sin valor por defecto a una tabla con dos millones de filas falla; hay que hacerlo en pasos.
3. CREATE INDEX CONCURRENTLY en producción. Un CREATE INDEX normal bloquea las escrituras de la tabla mientras dura. Es el ejemplo perfecto de cómo lo que aprendiste en 06-02 sobre bloqueos se traduce en una decisión operativa concreta.

Un esquema con doce filas no enseña nada. El planificador de consultas hará recorrido secuencial siempre, cualquier índice parecerá inútil y ningún problema de concurrencia se manifestará. Para aprender rendimiento necesitas volumen, y para eso hay tres caminos.

Es la vía más rápida y no requiere ninguna herramienta externa. Genera medio millón de préstamos verosímiles para BiblioRed:

Ese ANALYZE final no es un adorno. Es la causa número uno de "he creado el índice y sigue sin usarlo" en pruebas caseras: el planificador de 06-03 decide con estadísticas, y tras una carga masiva las estadísticas están obsoletas.

Una advertencia sobre el realismo: random() produce una distribución uniforme, y los datos reales nunca son uniformes. En BiblioRed unos pocos títulos concentran la mayoría de los préstamos, y esa asimetría es justo lo que hace interesantes los índices y los planes. Si quieres pruebas realistas, sesga la distribución a propósito.

pgbench merece una mención aparte porque hace algo que los otros no: carga concurrente. Con pgbench -c 20 -T 60 tienes veinte sesiones escribiendo a la vez durante un minuto, que es la forma de ver de verdad lo que en 06-02 viste con dos terminales.

A veces no quieres montar nada: quieres practicar consultas sobre un esquema no trivial que ya existe.

Se encuentran buscando su nombre; suelen distribuirse como un fichero SQL que se carga con psql -f. Con Chinook en SQLite tienes práctica de consultas en menos de un minuto y sin instalar ningún servidor.

Continuación directa de 06-03, donde leíste tu primer plan de ejecución.

pg_stat_statements merece su ficha porque cambia la forma de trabajar. Sin ella, optimizas la consulta que alguien se ha quejado de que va lenta. Con ella, optimizas la que más tiempo total consume, que muchas veces es una consulta rápida ejecutada cien mil veces al día y de la que nadie se queja.

Esa segunda consulta es la que ejecutarás el día en que la aplicación "se ha quedado colgada". Casi siempre la respuesta está ahí: una transacción abierta desde hace veinte minutos que nadie ha confirmado, bloqueando al resto. Es 06-02 en la vida real.

Continuación de 06-04. Aquí solo hay una regla que importe: una copia de seguridad que no se ha restaurado nunca no es una copia de seguridad, es una esperanza.

Lo mínimo, que puedes tener funcionando esta tarde:

Automatizarlo es un par de líneas más —una tarea programada que ejecute el volcado, lo comprima y lo copie a otro sitio— pero la parte que la gente omite no es la automatización, es la restauración de prueba. Pon en el calendario una prueba de restauración trimestral. Es la única forma de saber que existe la copia.

Todo lo anterior es el inventario completo. Esto es lo que necesitas de verdad para empezar mañana.

Y esto es lo que no necesitas todavía, dicho explícitamente para que no pierdas tiempo:

El consejo que resume el apartado: no acumules herramientas antes de necesitarlas. Cada herramienta instalada tiene un coste de mantenimiento, de actualización y de atención. Una herramienta se adopta cuando tienes un problema que te duele y ella lo resuelve, no cuando la ves recomendada en una lista, incluida esta.

Error 1: no tener un motor local. Trabajar solo contra una base de datos compartida o gestionada significa no poder experimentar: no puedes matar el proceso, llenar el disco, provocar un interbloqueo ni restaurar una copia encima. Todo lo interesante de este curso requiere una base de datos que puedas destruir.

Error 2: usar latest en las imágenes de contenedor. Un día actualizas y el formato de datos ya no es compatible con la versión anterior. Fija siempre la versión mayor.

Error 3: cambiar el esquema a mano en la consola. El ALTER TABLE que escribiste directamente en producción no está en ningún sitio: ni en el repositorio, ni en el entorno de tu compañero, ni en tu memoria dentro de tres semanas. Todo cambio de esquema, migración.

Error 4: probar el rendimiento con doscientas filas. Con ese volumen el recorrido secuencial siempre gana y no aprenderás nada sobre índices. Genera cientos de miles de filas y ejecuta ANALYZE.

Error 5: olvidar ANALYZE tras una carga masiva. Es la causa más frecuente de "el índice está creado pero no se usa". El planificador decide con estadísticas, y tras insertar medio millón de filas están obsoletas.

Error 6: confiar en una copia de seguridad no restaurada. Restaura sobre una base de datos nueva y cuenta las filas. Trimestralmente. Sin excepción.

Error 7: dejar transacciones abiertas en el cliente gráfico. Varios clientes trabajan en modo de transacción manual: abres una pestaña, ejecutas un UPDATE, te vas a comer, y el bloqueo se queda ahí parando a todo el mundo. Comprueba en qué modo está tu cliente y revisa pg_stat_activity cuando algo se atasque.

Error 8: instalar cuatro motores y no usar ninguno. El entusiasmo del módulo 3 lleva a instalar Cassandra y Neo4j "para probarlos". Instálalos cuando vayas a hacer algo concreto con ellos, y bórralos si en un mes no lo has hecho.

Consejo 1: versiona todo lo que rodea a la base de datos. El docker-compose.yml, las migraciones, el README con el erDiagram de Mermaid, los scripts de datos de prueba y el de copia de seguridad. Que clonar el repositorio y ejecutar dos comandos deje el entorno funcionando es un objetivo alcanzable y muy rentable.

Consejo 2: aprende psql antes que ningún cliente gráfico. El gráfico se aprende en veinte minutos cuando ya sabes lo que estás haciendo; al revés, el gráfico esconde lo que ocurre y frena el aprendizaje.

Consejo 3: ten siempre a mano un fichero de consultas de diagnóstico. Las de pg_stat_activity, pg_stat_statements, tamaño de tablas e índices y uso de índices. El día del incidente no es el momento de escribirlas.

Consejo 4: y de nuevo, la documentación oficial manda. Las versiones avanzan, las opciones cambian de nombre y los valores por defecto se revisan de una versión a otra. Ante cualquier duda entre lo que dice esta lección y lo que dice el manual de tu versión, el manual tiene razón.

Estos ejercicios son de práctica real: se resuelven con la máquina encendida, no de memoria. No hay una única respuesta correcta; las soluciones son respuestas modelo razonadas y tu versión puede ser distinta y mejor.

Levanta con Docker Compose el entorno de 08-03 (PostgreSQL + MongoDB + Redis), carga en PostgreSQL el esquema de VallBici o de BiblioRed y después:

1. Comprueba que los tres motores responden desde su cliente de consola.
2. Inserta al menos 300.000 filas en la tabla de trayectos o de préstamos con generate_series, y ejecuta ANALYZE.
3. Rómpelo a propósito: para el contenedor de Redis con la aplicación en marcha y documenta qué deja de funcionar y qué sigue funcionando. Después, ejecuta docker compose down (sin -v) y vuelve a levantar: comprueba que los datos siguen ahí.
4. Ejecuta docker compose down -v y vuelve a levantar: comprueba que no están, y explica por qué.
5. Deja el resultado en un repositorio con docker-compose.yml, los .sql de inicialización y un README que permita a otra persona reproducirlo en menos de diez minutos.

Coge el esquema de BiblioRed tal como lo dejaste en el módulo 5 y conviértelo en una secuencia de migraciones:

1. Elige una herramienta y justifica la elección en dos líneas.
2. Escribe V1 con el esquema base y, al menos, tres migraciones posteriores que representen cambios reales: un índice nuevo justificado por un EXPLAIN, una restricción de integridad que hoy está en la aplicación, y una columna nueva sobre una tabla que ya tiene datos.
3. La migración de la columna nueva debe poder ejecutarse sobre las 300.000 filas del ejercicio 1 sin dejar la tabla bloqueada un tiempo inaceptable. Explica cómo lo consigues.
4. Documenta en cada fichero por qué se hace el cambio, no solo qué se hace.
5. Comprueba lo esencial: borra la base de datos, ejecuta las migraciones desde cero y verifica que obtienes el mismo esquema.

Sin instalar nada nuevo todavía, escribe tu kit personal de herramientas para los próximos seis meses. Para cada pieza:

1. Qué herramienta eliges y para qué tarea concreta.
2. Contra qué alternativa la elegiste y por qué —una razón real, no "es la más popular".
3. Qué herramienta de la lección descartas explícitamente y en qué condición la reconsiderarías.
4. Añade una prueba de fuego: describe la tarea concreta con la que verificarás en un mes que la elección fue acertada.

Respuestas modelo, no las únicas correctas. Lo que se evalúa es el razonamiento y que la máquina realmente haga lo que dices.

Solución 1 (respuesta modelo)

Puntos 1 y 2. Comprobación de los tres motores y carga de volumen:

La carga se hace con el generate_series del apartado 8, seguido siempre de ANALYZE. Verificación: EXPLAIN (ANALYZE) de una consulta filtrada por socio debe pasar de recorrido secuencial a búsqueda por índice después de crear el índice y ejecutar ANALYZE; si no cambia, casi seguro falta el ANALYZE.

Punto 3 — romperlo. Con docker compose stop redis:

Esa tabla es la comprobación empírica de la tesis de 08-03: «que Redis pueda caerse sin impedir un solo cobro es la prueba de que el reparto está bien hecho». Si al parar Redis dejara de poderse cobrar, el reparto estaría mal y habría que revisarlo.

Puntos 4 y 5. docker compose down para los contenedores pero conserva los volúmenes con nombre (pgdata, mongodata, redisdata), así que al volver a levantar los datos están. down -v elimina esos volúmenes y, con ellos, los datos; además, al recrearse el volumen de PostgreSQL vacío, se vuelven a ejecutar los scripts de docker-entrypoint-initdb.d, que solo corren cuando el directorio de datos está sin inicializar. Entender esa asimetría es justo el objetivo del ejercicio: el contenedor es desechable, el volumen no.

Solución 2 (respuesta modelo)

1. Elección: ficheros SQL numerados con Flyway o una herramienta ligera equivalente. Razón: BiblioRed no usa ningún marco de trabajo con migraciones propias, el esquema se piensa en SQL y quiero que lo que se aplica sea exactamente lo que leo, sin capa de abstracción intermedia.

2 y 3. La migración delicada —añadir una columna NOT NULL a una tabla de 300.000 filas— se hace en tres pasos, no en uno:

El índice justificado por EXPLAIN es el V3 del apartado 7, con CONCURRENTLY y con el orden de columnas razonado. La restricción que sube de la aplicación al motor es el V4 de las reservas de salas sin solapes.

4 y 5. El comentario de cabecera de cada fichero explica el porqué —el ticket, el plan de ejecución que lo motivó, la lección del curso que lo fundamenta— porque dentro de un año el "qué" se lee en el SQL y el "por qué" no está en ninguna parte. La verificación final es la que da sentido a todo el ejercicio: dropdb bibliored && createdb bibliored, aplicar las migraciones desde cero y comparar el esquema resultante (pg_dump --schema-only) con el de la base de datos original. Si no coinciden, hay algún cambio que se hizo a mano y no está en ninguna migración: exactamente el problema que este apartado viene a resolver.

Solución 3 (respuesta modelo)

Descartes explícitos. Elasticsearch y Neo4j: no los instalo hasta tener un requisito de búsqueda con tolerancia a erratas o de recorrido de grafos que PostgreSQL con pg_trgm o consultas recursivas no cubra. pgBackRest: no hasta que administre una base de datos de la que dependa alguien que no sea yo; mientras tanto, pg_dump automatizado y restaurado trimestralmente. Cliente comercial de pago: no hasta que DBeaver me estorbe de verdad.

Empecemos por lo pequeño y acabemos por lo grande.

Lo pequeño: de todo el inventario de esta lección, seis piezas bastan —PostgreSQL local, psql, Docker Compose, un cliente gráfico, una herramienta de migraciones y EXPLAIN con pg_stat_statements—. Con eso puedes diseñar, medir, versionar y recuperar, que es todo lo que hace falta para trabajar bien. Añade herramientas cuando un problema real te las pida, y no antes. Y recuerda las dos advertencias que gobiernan todo el módulo 9: versiones, licencias, precios y planes gratuitos cambian sin aviso, y la documentación oficial manda sobre cualquier curso, incluido este.

Y ahora lo grande, porque con esta lección se cierra el curso entero.

Han sido nueve módulos y treinta y seis lecciones. Merece la pena mirar atrás el recorrido completo, porque desde dentro no siempre se ve.

Empezaste en 01-01 con una pregunta que parecía ingenua: qué es una base de datos y por qué no basta con una hoja de cálculo. La respuesta ocupó el módulo 1 entero —tipos de bases de datos, cincuenta años de historia desde los sistemas jerárquicos hasta hoy, y la arquitectura por dentro de un gestor—. En el módulo 2 aprendiste el modelo relacional y SQL de verdad: no solo SELECT, sino uniones de varias tablas, agregación, subconsultas correlacionadas e integridad referencial, con la idea que lo vertebra todo: si la regla es de integridad, vive en la base de datos. El módulo 3 te sacó de ahí a propósito para enseñarte NoSQL, sus cuatro familias y su modelado, y sobre todo para que vieras el modelo relacional desde fuera y entendieras que es una elección y no una ley natural.

Los módulos 4 y 5 fueron los del oficio silencioso: diseñar. Diagramas entidad-relación, transformación a esquemas, tipos de datos y restricciones, dependencias funcionales, formas normales hasta la de Boyce-Codd, y —la parte que muchos cursos no cuentan— desnormalizar a propósito y saber justificar por qué. El módulo 6 puso el sistema bajo presión: transacciones y ACID, dos terminales abiertos viendo con tus propios ojos una actualización perdida, planes de ejecución leídos línea a línea, permisos y copias de seguridad. El módulo 7 fueron cuatro lecciones de ejercicios sin red. Y el módulo 8 te hizo construir de cero: BiblioRed en relacional, VallBici en documental, y finalmente cuatro motores repartiéndose un servicio municipal con una tabla que declaraba, campo a campo, quién manda sobre qué.

Qué sabes hacer ahora. Puedes sentarte delante de un dominio que no conoces, hacer las preguntas correctas, dibujar el modelo, transformarlo en tablas con sus tipos y sus restricciones, normalizarlo, decidir dónde conviene romper la normalización y defenderlo. Puedes escribir consultas multitabla con agregación sin buscar la sintaxis. Puedes leer un plan de ejecución, decidir un índice y justificar el orden de sus columnas. Puedes razonar qué nivel de aislamiento necesita una operación y qué anomalía estás aceptando. Puedes decidir si un problema pide un documento, una clave-valor, un grafo o una tabla, y —más importante— cuándo no lo pide. Y puedes montar el entorno, versionarlo y recuperarlo.

Eso no es poco. Es, con bastante precisión, lo que se espera de alguien que trabaja con datos con criterio.

Qué falta, dicho con honestidad: la experiencia. Ninguna lección da lo que da haber tenido una base de datos en producción con gente dependiendo de ella. Nadie entiende del todo por qué las copias se prueban hasta que ha necesitado una; nadie interioriza los niveles de aislamiento hasta que ha visto dos cobros duplicados un martes por la mañana. Eso llega con el tiempo, y este curso lo único que ha hecho —que ya es bastante— es prepararte para reconocerlo cuando pase, en lugar de sufrirlo sin entenderlo.

Así que la invitación final es la misma que cerraba 08-03, y ahora tienes todas las herramientas para aceptarla: elige uno de los casos —el BiblioRed relacional de los módulos 4 y 5, el VallBici documental de 08-02, o el políglota de 08-03—, móntalo en tu máquina con el docker-compose.yml de esta lección, cárgalo con medio millón de filas, y rómpelo. Mata el contenedor de Redis y mira qué sigue funcionando. Abre dos terminales y provoca un interbloqueo. Borra la base de datos entera y restáurala desde tu copia. Crea un índice que no sirva para nada y averigua con EXPLAIN por qué no sirve. Cada una de esas cosas te enseñará más que releer la lección correspondiente, porque el conocimiento que se queda es el que se paga con un error propio.

Gracias por llegar hasta aquí. Treinta y seis lecciones son muchas, y terminar un curso completo —no abandonarlo en el módulo 3, que es lo que le pasa a la mayoría de la gente con la mayoría de los cursos— dice algo real sobre cómo trabajas. Las bases de datos son una de las pocas áreas de la informática donde lo que aprendes envejece despacio: el artículo de Codd tiene más de cincuenta años y sigue siendo la base de lo que has estudiado, y las decisiones que ahora sabes tomar te seguirán sirviendo cuando cambien los lenguajes, los marcos de trabajo y las modas.

Ya no hay siguiente lección. Hay una base de datos vacía esperando a que decidas qué va dentro. Suerte con ella.