Por qué aprender SQL dentro de un contenedor
Aprender bases de datos relacionales tiene un obstáculo que poco tiene que ver con SQL: preparar el entorno. Instalar PostgreSQL en el sistema operativo, configurar usuarios y contraseñas, lidiar con servicios que no arrancan, rutas que no aparecen en el PATH o versiones que no coinciden con las de un tutorial puede consumir más tiempo que la primera lección. Y cuando algo se rompe, deshacer los cambios en la máquina es todavía más complicado.
Los contenedores resuelven ese problema de raíz. Con Docker y la extensión Dev Containers de Visual Studio Code puedes definir en un par de archivos todo lo que necesita tu entorno de prácticas: el sistema base, el cliente de PostgreSQL, Git, Bash, Nano y el propio servidor de base de datos. Cualquier persona que abra el proyecto obtiene exactamente el mismo resultado, en Windows, macOS o Linux, y si algo sale mal basta con reconstruir el contenedor para volver a empezar.
Si a eso se suma CodeRoad, una extensión de VS Code que ejecuta tutoriales interactivos paso a paso, el resultado es un laboratorio completo: lees una instrucción, escribes el comando o la consulta en la terminal integrada, y la extensión comprueba automáticamente si lo has hecho bien antes de pasar al siguiente paso.
En esta guía construiremos ese entorno desde cero con las versiones actuales de cada herramienta. Veremos cómo definir el contenedor de desarrollo en VS Code, cómo levantar PostgreSQL 18 con Docker Compose, cómo funcionan y cómo se inician los tutoriales de CodeRoad, cómo crear los tuyos propios y cómo resolver los problemas más frecuentes. También revisaremos alternativas para que elijas el enfoque que mejor encaja contigo o con tu equipo.
Las piezas que componen el entorno
Antes de escribir configuración conviene tener claro qué papel cumple cada componente:
- Docker Engine ejecuta los contenedores. En Windows y macOS se suele usar a través de Docker Desktop; en Linux puede instalarse directamente.
- Visual Studio Code es el editor desde el que trabajarás.
- La extensión Dev Containers permite que VS Code se conecte a un contenedor y trabaje dentro de él como si fuera tu máquina local: la terminal, las extensiones y los archivos viven en el contenedor.
- PostgreSQL es el motor de base de datos relacional sobre el que practicarás SQL.
- CodeRoad es la extensión que reproduce tutoriales interactivos basados en Git y pruebas automáticas.
- Git es necesario tanto para clonar los proyectos como para el funcionamiento interno de CodeRoad.
La idea clave de los Dev Containers es que tu sistema operativo solo necesita Docker, VS Code y Git. Todo lo demás, incluido PostgreSQL, se instala dentro de los contenedores y desaparece cuando ya no lo necesitas.
Versiones actuales y requisitos
A finales de octubre de 2026, las versiones estables de referencia son las siguientes:
- PostgreSQL 18, cuya última versión menor es la 18.6. PostgreSQL 19 está en fase de release candidate y su publicación general está prevista para noviembre de 2026, por lo que no se recomienda todavía para un entorno estable.
- Visual Studio Code 1.143, la versión estable más reciente.
- Docker Engine en la serie 29.
- Git 2.56.
Ten en cuenta también que PostgreSQL 14 deja de recibir correcciones el 12 de noviembre de 2026. Si encuentras material de aprendizaje que fija esa versión, no hay ningún inconveniente en practicar con la 18: los fundamentos de SQL que se enseñan en cualquier tutorial introductorio funcionan igual.
En cuanto a hardware, el entorno es ligero. Con 8 GB de RAM y unos pocos gigabytes libres de disco para las imágenes es suficiente. La primera construcción del contenedor es la más lenta, porque descarga imágenes base y paquetes; las siguientes aperturas tardan apenas unos segundos.
Instalar los requisitos en tu sistema
En Windows y macOS, la forma más sencilla de obtener Docker es Docker Desktop. En Windows, asegúrate de que utiliza el backend de WSL 2, que ofrece mucho mejor rendimiento que la virtualización tradicional. En Linux puedes instalar Docker Engine desde el repositorio oficial de tu distribución. Por ejemplo, en Ubuntu, tras configurar el repositorio de Docker siguiendo su documentación:
sudo apt-get install docker-ce docker-ce-cli containerd.io \
docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker "$USER"
Cierra sesión y vuelve a entrar para que el cambio de grupo surta efecto. Después comprueba que todo funciona:
docker --version
docker compose version
git --version
code --version
Docker version 29.x.x, build xxxxxxx
Docker Compose version v2.x.x
git version 2.56.0
1.143.0
Los números exactos de las versiones menores variarán según tu instalación. Lo importante es que los cuatro comandos respondan sin errores.
Por último, instala la extensión Dev Containers en VS Code. Puedes hacerlo desde la vista de extensiones o desde la terminal:
code --install-extension ms-vscode-remote.remote-containers
No necesitas instalar CodeRoad en tu máquina: la configuraremos para que se instale automáticamente dentro del contenedor.
Estructura del proyecto de prácticas
Vamos a crear un proyecto propio llamado laboratorio-sql. Toda la configuración del contenedor vive en la carpeta .devcontainer, y el resto del repositorio queda libre para tus ejercicios:
laboratorio-sql/
├── .devcontainer/
│ ├── devcontainer.json
│ ├── docker-compose.yml
│ └── Dockerfile
├── scripts/
│ └── informe.sh
└── sql/
└── 01_esquema.sql
Créala desde la terminal:
mkdir -p laboratorio-sql/{.devcontainer,scripts,sql}
cd laboratorio-sql
git init
Versionar el proyecto con Git desde el principio tiene una ventaja adicional: si compartes el repositorio, cualquier persona puede clonarlo y obtener exactamente el mismo entorno de desarrollo reproducible con un solo comando de VS Code.
Definir PostgreSQL y el espacio de trabajo con Docker Compose
Usaremos dos servicios. El primero, espacio, es el contenedor donde trabajarás: tiene Bash, Git, Nano, el cliente psql y Node.js para las herramientas de CodeRoad. El segundo, db, es el servidor PostgreSQL 18 con la imagen oficial. Separarlos permite actualizar o reiniciar la base de datos sin tocar tu entorno de trabajo.
El archivo .devcontainer/docker-compose.yml queda así:
services:
espacio:
build:
context: .
dockerfile: Dockerfile
volumes:
- ..:/workspaces/laboratorio-sql:cached
command: sleep infinity
environment:
PGHOST: db
PGUSER: alumno
PGPASSWORD: practica
PGDATABASE: laboratorio
depends_on:
db:
condition: service_healthy
db:
image: postgres:18
restart: unless-stopped
environment:
POSTGRES_USER: alumno
POSTGRES_PASSWORD: practica
POSTGRES_DB: laboratorio
volumes:
- datos-postgres:/var/lib/postgresql
healthcheck:
test: ["CMD-SHELL", "pg_isready -U alumno -d laboratorio"]
interval: 5s
timeout: 3s
retries: 10
volumes:
datos-postgres:
Hay varios detalles que conviene destacar. Las variables PGHOST, PGUSER, PGPASSWORD y PGDATABASE son las que lee el cliente psql, de modo que dentro del contenedor bastará con escribir psql para conectarte sin parámetros. El healthcheck con pg_isready garantiza que el espacio de trabajo no arranque hasta que la base de datos acepte conexiones. Y el volumen con nombre datos-postgres mantiene tus tablas aunque reconstruyas los contenedores.
En las imágenes oficiales de PostgreSQL 18 el volumen se monta en /var/lib/postgresql, un cambio respecto a versiones anteriores, que usaban /var/lib/postgresql/data. Si copias configuraciones antiguas, revisa esta ruta.
El Dockerfile del espacio de trabajo parte de la imagen base de Dev Containers e instala las herramientas de línea de comandos:
FROM mcr.microsoft.com/devcontainers/base:ubuntu
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
postgresql-client nano less \
&& rm -rf /var/lib/apt/lists/*
El cliente psql que instala Ubuntu puede ser de una versión mayor anterior a la del servidor. Para practicar SQL estándar no supone ningún problema, aunque psql mostrará un aviso al conectarte. Si quieres que coincidan exactamente, puedes instalar el cliente desde el repositorio oficial de paquetes de PostgreSQL.
Configurar devcontainer.json
El archivo devcontainer.json le dice a VS Code cómo construir y abrir el entorno. Aquí indicamos qué servicio de Compose usar, en qué carpeta trabajar, qué extensiones instalar dentro del contenedor y qué características adicionales añadir:
{
"name": "Laboratorio SQL",
"dockerComposeFile": "docker-compose.yml",
"service": "espacio",
"workspaceFolder": "/workspaces/laboratorio-sql",
"shutdownAction": "stopCompose",
"features": {
"ghcr.io/devcontainers/features/node:1": {
"version": "lts"
},
"ghcr.io/devcontainers/features/git:1": {}
},
"customizations": {
"vscode": {
"extensions": ["CodeRoad.coderoad"],
"settings": {
"terminal.integrated.defaultProfile.linux": "bash"
}
}
},
"postCreateCommand": "psql -c 'SELECT version();'"
}
Las features son piezas reutilizables que añaden herramientas al contenedor sin tener que escribir instrucciones en el Dockerfile. En este caso, Node.js en su versión LTS, necesario para la CLI de CodeRoad, y una versión actual de Git.
El postCreateCommand se ejecuta una sola vez, al crear el contenedor, y nos sirve como prueba rápida de que la conexión con PostgreSQL funciona. Si ese comando falla, sabrás desde el primer momento que algo en la configuración de red o de credenciales no está bien.
Si el identificador de la extensión no coincide con el que muestra el Marketplace en el momento en que leas esto, cópialo desde la página de la extensión: en la vista de extensiones de VS Code, el menú contextual ofrece la opción de copiar su identificador.
Abrir el proyecto en el contenedor
Con los tres archivos listos, abre la carpeta en VS Code:
code .
VS Code detectará la carpeta .devcontainer y mostrará una notificación para reabrir el proyecto en el contenedor. Si no aparece, abre la paleta de comandos con Ctrl+Shift+P (o Cmd+Shift+P en macOS) y ejecuta:
Dev Containers: Reopen in Container
La primera vez, Docker descargará las imágenes, construirá el espacio de trabajo e instalará las extensiones. Puede tardar varios minutos según tu conexión. Cuando termine, la esquina inferior izquierda de VS Code indicará que estás conectado al contenedor “Laboratorio SQL” y la terminal integrada se abrirá dentro de él.
Si más adelante modificas el Dockerfile o el devcontainer.json, los cambios no se aplican solos. Debes ejecutar:
Dev Containers: Rebuild Container
Este comando reconstruye la imagen y vuelve a crear el contenedor. Los archivos de tu proyecto se conservan porque están montados desde tu máquina, y los datos de PostgreSQL también, gracias al volumen con nombre.
Primeros pasos con psql
Abre una terminal en VS Code, que ya está dentro del contenedor, y conéctate a la base de datos:
psql
psql (16.x, server 18.6)
WARNING: psql major version 16, server major version 18.
Some psql features might not work.
Type "help" for help.
laboratorio=#
El aviso confirma lo que comentamos antes sobre la diferencia de versiones; puedes ignorarlo para el trabajo habitual. Desde aquí ya puedes explorar con los metacomandos de psql, que empiezan por una barra invertida:
\l -- lista las bases de datos
\dt -- lista las tablas de la base actual
\d+ libros -- describe una tabla con detalle
\q -- sale de psql
Y, por supuesto, ejecutar SQL estándar:
CREATE TABLE autores (
id SERIAL PRIMARY KEY,
nombre VARCHAR(80) NOT NULL,
pais VARCHAR(40)
);
INSERT INTO autores (nombre, pais)
VALUES ('Rosario Castellanos', 'México'),
('Julio Cortázar', 'Argentina');
SELECT nombre FROM autores WHERE pais = 'México';
nombre
---------------------
Rosario Castellanos
(1 row)
Con esto tienes una base de datos de práctica completamente aislada, que puedes romper y reconstruir tantas veces como quieras.
Cómo funcionan los tutoriales de CodeRoad
CodeRoad ofrece tutoriales interactivos dentro del editor construidos sobre Git. Cada tutorial se organiza en niveles y cada nivel en pasos. Para cada paso, el autor prepara en un repositorio una serie de commits: uno con el estado inicial y las pruebas que deben superarse, y opcionalmente otro con la solución.
Cuando sigues un tutorial, CodeRoad aplica en tu espacio de trabajo los commits correspondientes al paso actual, muestra las instrucciones escritas en Markdown en un panel lateral y ejecuta las pruebas cada vez que guardas o cuando lo solicitas. Si las pruebas pasan, el paso se marca como completado y la extensión avanza al siguiente.
La descripción completa de un tutorial se recoge en un archivo tutorial.json. Ese archivo contiene los niveles, los pasos, los textos, las pistas y la referencia al repositorio y a los commits que la extensión debe aplicar. Por eso, para empezar un tutorial, lo único que necesitas es la URL de su tutorial.json.
Para los tutoriales de SQL y Bash, las pruebas suelen comprobar el estado real del entorno: si existe una tabla, si una columna tiene el tipo correcto, si un script devuelve la salida esperada o si un archivo contiene ciertos comandos. Por eso es tan importante que el contenedor tenga exactamente las herramientas que el tutorial espera.
Iniciar un tutorial interactivo
Con el contenedor en marcha y la extensión instalada, el proceso para empezar es siempre el mismo. Abre la paleta de comandos y ejecuta:
CodeRoad: Start
Se abrirá el panel de CodeRoad. Elige la opción para iniciar un nuevo tutorial, selecciona la pestaña de URL y pega la dirección del archivo tutorial.json del tutorial que quieres seguir. Suele ser una URL al archivo en bruto dentro del repositorio del tutorial, con una forma parecida a esta:
https://raw.githubusercontent.com/organizacion/tutorial-sql-biblioteca/main/tutorial.json
Pulsa el botón para comenzar y la extensión cargará el primer nivel. A partir de ahí, el flujo es leer la instrucción, ejecutar lo que se pide en la terminal o editar el archivo indicado y comprobar el resultado.
Muchos tutoriales de bases de datos esperan que el contenedor tenga una configuración concreta: un usuario determinado, una base de datos con cierto nombre o rutas específicas. Si el tutorial que quieres seguir incluye su propio repositorio con carpeta .devcontainer, lo más fiable es clonar ese repositorio y abrirlo en contenedor en lugar de usar el tuyo. Así te aseguras de que las pruebas encuentran exactamente el entorno para el que fueron escritas.
Reiniciar o cambiar de tutorial
CodeRoad guarda el progreso del tutorial en curso. Si quieres empezar desde cero o pasar a otro tutorial, la forma más limpia es reconstruir el contenedor y luego iniciar el nuevo tutorial con su URL:
Dev Containers: Rebuild Container
CodeRoad: Start
Ten en cuenta que reiniciar borra el progreso del tutorial actual y puede eliminar los archivos que creaste durante él, porque la extensión restablece el estado del espacio de trabajo. Antes de cambiar, guarda fuera del proyecto cualquier script o consulta que quieras conservar, o súbelos a otro repositorio.
En el caso de la base de datos, recuerda que el volumen persistente conserva las tablas entre reconstrucciones. Si un tutorial nuevo espera una base de datos vacía, puedes eliminar el volumen desde tu máquina, fuera del contenedor:
docker compose -f .devcontainer/docker-compose.yml down -v
El parámetro -v elimina también los volúmenes con nombre. Úsalo solo cuando realmente quieras borrar todos los datos.
Crear tu propio tutorial con la CLI de CodeRoad
Una de las ventajas de este enfoque es que no estás limitado a los tutoriales que ya existen. Si enseñas SQL, formas a personas nuevas en tu equipo o quieres documentar el modelo de datos de un proyecto, puedes escribir tus propios tutoriales con la CLI oficial. Dentro del contenedor, gracias a la feature de Node.js, basta con:
npm install -g @coderoad/cli
coderoad create
El comando create genera dos archivos de plantilla. TUTORIAL.md contiene los textos, organizados por niveles y pasos con identificadores numéricos:
# Biblioteca en PostgreSQL
Aprende a modelar una biblioteca con tablas relacionadas.
## 1. Crear las tablas básicas
Empezaremos por los autores y los libros.
### 1.1 Tabla de autores
Crea una tabla `autores` con las columnas `id` y `nombre`.
#### HINTS
- Usa `SERIAL PRIMARY KEY` para el identificador.
- El nombre no debería aceptar valores nulos.
coderoad.yaml contiene la configuración: niveles, pasos y, para cada paso, los archivos y comandos de preparación y de solución. La conexión entre ambos archivos y el código está en los mensajes de commit del repositorio del tutorial: un commit cuyo mensaje empieza por 1.1 contiene la preparación y las pruebas del paso 1.1, y uno que empieza por 1.1S contiene la solución.
Cuando todo está listo, se genera el archivo final:
coderoad build
El resultado es un tutorial.json que puedes publicar en el repositorio y compartir con su URL. Las pruebas pueden escribirse con el ejecutor que elijas; para tutoriales de SQL es habitual que las pruebas lancen consultas a la base de datos y comprueben, por ejemplo, que una tabla existe en information_schema.
Ejercicio práctico: modelar una biblioteca
Para aprovechar el entorno sin depender de ningún tutorial externo, vamos a construir un pequeño modelo relacional. Guarda este contenido en sql/01_esquema.sql:
DROP TABLE IF EXISTS prestamos, libros, autores CASCADE;
CREATE TABLE autores (
id SERIAL PRIMARY KEY,
nombre VARCHAR(80) NOT NULL
);
CREATE TABLE libros (
id SERIAL PRIMARY KEY,
titulo VARCHAR(120) NOT NULL,
anio INT CHECK (anio > 1400),
autor_id INT NOT NULL REFERENCES autores(id)
);
CREATE TABLE prestamos (
id SERIAL PRIMARY KEY,
libro_id INT NOT NULL REFERENCES libros(id),
lector VARCHAR(80) NOT NULL,
fecha_inicio DATE NOT NULL DEFAULT CURRENT_DATE,
fecha_fin DATE
);
INSERT INTO autores (nombre) VALUES
('Rosario Castellanos'), ('Juan Rulfo'), ('Elena Poniatowska');
INSERT INTO libros (titulo, anio, autor_id) VALUES
('Balún Canán', 1957, 1),
('Pedro Páramo', 1955, 2),
('El llano en llamas', 1953, 2),
('La noche de Tlatelolco', 1971, 3);
INSERT INTO prestamos (libro_id, lector, fecha_fin) VALUES
(2, 'Mariana', NULL),
(4, 'Tomás', '2026-10-20');
Ejecútalo desde la terminal del contenedor:
psql -f sql/01_esquema.sql
Ahora puedes practicar consultas con uniones y agregaciones. Por ejemplo, qué libros están prestados en este momento:
SELECT l.titulo, a.nombre AS autor, p.lector
FROM prestamos p
JOIN libros l ON l.id = p.libro_id
JOIN autores a ON a.id = l.autor_id
WHERE p.fecha_fin IS NULL;
titulo | autor | lector
--------------+------------+---------
Pedro Páramo | Juan Rulfo | Mariana
(1 row)
O cuántos libros tiene cada autor:
SELECT a.nombre, COUNT(l.id) AS total
FROM autores a
LEFT JOIN libros l ON l.autor_id = a.id
GROUP BY a.nombre
ORDER BY total DESC;
Este tipo de ejercicio, con claves primarias, claves foráneas, restricciones CHECK y uniones, cubre los fundamentos que necesitas para cualquier proyecto con bases de datos relacionales.
Consultas SQL desde Bash
Una parte importante del trabajo con bases de datos es automatizar tareas desde la línea de comandos: cargar datos, generar informes o ejecutar migraciones. El contenedor ya tiene todo lo necesario para lanzar consultas SQL desde Bash con psql. Crea el archivo scripts/informe.sh:
#!/usr/bin/env bash
set -euo pipefail
PSQL="psql --no-align --tuples-only --field-separator=|"
echo "Informe de préstamos activos"
echo "----------------------------"
$PSQL -c "
SELECT l.titulo, p.lector, p.fecha_inicio
FROM prestamos p
JOIN libros l ON l.id = p.libro_id
WHERE p.fecha_fin IS NULL
ORDER BY p.fecha_inicio;
" | while IFS='|' read -r titulo lector fecha; do
echo "${titulo} -> ${lector} (desde ${fecha})"
done
Dale permisos de ejecución y lánzalo:
chmod +x scripts/informe.sh
./scripts/informe.sh
Informe de préstamos activos
----------------------------
Pedro Páramo -> Mariana (desde 2026-10-27)
Las opciones --no-align, --tuples-only y --field-separator convierten la salida de psql en texto fácil de procesar línea a línea. Como el script usa las variables de entorno definidas en Compose, no necesita contraseñas escritas en el código. Y la instrucción set -euo pipefail hace que el script se detenga ante cualquier error en lugar de continuar con datos incompletos.
Persistencia de datos y copias de seguridad
El volumen con nombre que definimos en Compose sobrevive a reconstrucciones del contenedor, pero no es una copia de seguridad. Si eliminas el volumen, o si quieres llevar tus datos a otra máquina, necesitas exportarlos. pg_dump es la herramienta estándar para ello:
pg_dump --format=custom --file=respaldo-laboratorio.dump laboratorio
Y para restaurar en una base de datos vacía:
pg_restore --clean --if-exists --dbname=laboratorio respaldo-laboratorio.dump
El formato custom está comprimido y permite restaurar selectivamente tablas concretas. Si prefieres un archivo SQL legible, omite el parámetro de formato y obtendrás un script de texto plano.
Ten presente que pg_dump debe ser de la misma versión mayor que el servidor o más reciente. Si tu cliente es de una versión anterior, la herramienta se negará a exportar. En ese caso puedes ejecutar el volcado directamente en el contenedor del servidor, que siempre tiene las herramientas de su misma versión:
docker compose -f .devcontainer/docker-compose.yml exec db \
pg_dump -U alumno --format=custom laboratorio > respaldo-laboratorio.dump
Rendimiento en Windows y macOS
En Linux, los contenedores se ejecutan de forma nativa y el acceso a los archivos montados es prácticamente igual de rápido que trabajar sin contenedores. En Windows y macOS, Docker se ejecuta dentro de una máquina virtual, y los montajes de carpetas del sistema anfitrión pueden ser notablemente más lentos.
En Windows, la recomendación más importante es clonar el repositorio dentro del sistema de archivos de WSL 2 y no en una ruta de Windows como C:\Users\.... Desde una terminal de WSL:
cd ~
git clone https://github.com/tu-usuario/laboratorio-sql.git
cd laboratorio-sql
code .
VS Code se abrirá conectado a WSL y desde ahí podrás reabrir en contenedor. El acceso a disco será mucho más rápido.
Otra opción, válida en cualquier sistema, es el comando de Dev Containers que clona el repositorio directamente en un volumen de Docker:
Dev Containers: Clone Repository in Container Volume...
Con esta opción, el código no vive en tu sistema de archivos sino en un volumen gestionado por Docker, lo que elimina el coste de sincronizar archivos entre el anfitrión y la máquina virtual. Es especialmente útil en macOS.
Errores comunes y solución de problemas
La mayoría de los problemas con este tipo de entorno se repiten y tienen solución rápida.
Si VS Code muestra un error al abrir en contenedor indicando que no puede conectar con Docker, el servicio no está en marcha. Inicia Docker Desktop o, en Linux, el servicio de Docker, y comprueba que tu usuario puede usarlo:
docker ps
permission denied while trying to connect to the Docker daemon socket
Este mensaje en Linux indica que tu usuario no pertenece al grupo docker. Añádelo como vimos al principio y vuelve a iniciar sesión.
Si psql no consigue conectar, el mensaje suele ser explícito:
psql: error: could not translate host name "db" to address: Name or service not known
Significa que el contenedor de trabajo no está en la misma red que el de la base de datos, normalmente porque abriste el proyecto con una configuración distinta a la de Compose. Verifica que devcontainer.json apunta a docker-compose.yml y al servicio espacio, y reconstruye el contenedor.
Si el error es de autenticación, recuerda que las variables POSTGRES_USER y POSTGRES_PASSWORD solo se aplican la primera vez que se inicializa el volumen. Si las cambiaste después, el servidor sigue usando las antiguas. Elimina el volumen con down -v para inicializarlo de nuevo con los valores actuales.
Si el comando CodeRoad: Start no aparece en la paleta, la extensión no se instaló dentro del contenedor. Revisa el identificador en customizations.vscode.extensions, comprueba en la vista de extensiones que figura como instalada en el contenedor y no solo en local, y reconstruye si es necesario.
Si las pruebas de un tutorial fallan aunque creas haber hecho lo correcto, revisa que el entorno coincide con el que espera el tutorial: nombre de usuario, base de datos, ruta del proyecto o versión de las herramientas. Los tutoriales de SQL suelen comprobar el estado real de la base de datos, y una diferencia mínima en la configuración basta para que una prueba falle.
Por último, si la construcción falla por falta de espacio, limpia imágenes y cachés que ya no uses:
docker system df
docker builder prune
docker image prune
Comparativa con otras formas de practicar SQL
El entorno con Docker y Dev Containers no es la única opción para aprender SQL. Conviene conocer las alternativas para decidir con criterio.
Instalar PostgreSQL directamente en el sistema operativo es lo más directo y no requiere Docker. A cambio, mezcla el entorno de aprendizaje con tu máquina, complica tener varias versiones a la vez y hace más difícil volver a un estado limpio.
Los entornos de desarrollo en la nube, como GitHub Codespaces, utilizan el mismo formato de devcontainer.json. El proyecto que hemos construido funciona tal cual en ellos, sin instalar nada localmente, aunque dependen de una conexión estable y, más allá de la cuota gratuita, tienen coste.
Los editores SQL en línea son útiles para probar consultas sueltas, pero no permiten practicar Bash, Git ni la administración real de una base de datos.
Las herramientas gráficas como pgAdmin o DBeaver son excelentes complementos para explorar datos visualmente, y pueden conectarse al contenedor si publicas el puerto de PostgreSQL. Sin embargo, no sustituyen el dominio de psql y de la línea de comandos, que es lo que encontrarás en servidores reales.
Para quien quiere aprender bases de datos relacionales junto con la terminal, Bash y Git, el enfoque de contenedores ofrece el mejor equilibrio entre realismo, aislamiento y facilidad de puesta en marcha.
Conclusiones
Montar un laboratorio de bases de datos con Docker, VS Code, Dev Containers y PostgreSQL 18 elimina el principal obstáculo para aprender SQL: la configuración del entorno. Con tres archivos dentro de .devcontainer obtienes un espacio de trabajo idéntico en cualquier sistema operativo, con su propio servidor de base de datos, herramientas de línea de comandos y extensiones listas para usar.
CodeRoad añade una capa de aprendizaje guiado sobre ese entorno, con instrucciones paso a paso y pruebas automáticas que validan cada avance. Y gracias a su CLI, el mismo sistema sirve para crear tutoriales propios para equipos, clases o documentación interna.
Más allá de los tutoriales, lo que construyes al trabajar así son hábitos profesionales: definir entornos como código, separar servicios con Docker Compose, gestionar credenciales mediante variables de entorno, automatizar consultas con Bash y respaldar datos con pg_dump. Son las mismas prácticas que encontrarás en proyectos reales, y empezar a usarlas desde el aprendizaje marca una diferencia notable cuando llega el momento de trabajar con bases de datos en producción.