DBeaver: una herramienta para administrar PostgreSQL, MySQL y otras bases de datos

Una aplicación devuelve un precio incorrecto. Antes de modificar el código, necesitas comprobar qué valor guarda la base de datos, cómo se relaciona con otras tablas y si una actualización quedó confirmada. Para responder esas preguntas sirve un cliente como DBeaver: permite explorar la estructura, ejecutar SQL y revisar resultados desde una misma interfaz.

La comodidad también exige atención. Editar una celda puede terminar ejecutando un UPDATE, y guardar ese cambio no siempre significa lo mismo que confirmar una transacción. Aprender a distinguir esas operaciones importa más que memorizar todos los botones.

Vamos a utilizar DBeaver Community con una pequeña tienda ficticia en PostgreSQL. El laboratorio funciona en Docker, no requiere una base de datos externa y permite practicar consultas, metadatos y cambios reversibles.

Qué es DBeaver y qué hace Community

DBeaver es un cliente de bases de datos. Se conecta a un motor que almacena los datos y ejecuta las operaciones; instalar DBeaver no instala automáticamente un servidor PostgreSQL o MySQL.

Community es la edición gratuita y de código abierto, publicada con licencia Apache. Utiliza controladores, principalmente JDBC, para comunicarse con distintos motores. JDBC es una interfaz de acceso a bases de datos del ecosistema Java; el controlador traduce la comunicación con cada sistema. Entre los motores compatibles están PostgreSQL, MySQL, MariaDB, SQLite, Oracle y SQL Server. Consulta la descripción oficial de Community.

Compartir una interfaz no vuelve intercambiables esos motores. Sus tipos de datos, dialectos SQL, permisos y herramientas administrativas siguen siendo diferentes. Un script PostgreSQL puede necesitar cambios para funcionar en MySQL.

Para este tutorial basta con Community:

La matriz de formatos de transferencia y la documentación de Master Password permiten comprobar esas dos últimas diferencias. No conviene seguir una guía comercial suponiendo que todas sus opciones existen en Community.

Las ediciones comerciales incorporan distintas combinaciones de funciones empresariales, integraciones y acceso a sistemas NoSQL. Antes de elegir una licencia, revisa la comparación vigente de ediciones: no todas incluyen lo mismo.

Instalación en macOS, Linux y Windows

Descarga DBeaver Community desde su página oficial y elige el paquete correspondiente a tu sistema y arquitectura:

• macOS: abre el DMG y copia la aplicación a Aplicaciones. Hay paquetes para Apple Silicon e Intel. Con Homebrew también puedes ejecutar brew install --cask dbeaver-community.
• Windows: utiliza el instalador o la distribución ZIP oficial. Selecciona la arquitectura adecuada para tu equipo.
• Linux: utiliza el paquete DEB o RPM apropiado para tu distribución, o una de las alternativas indicadas en la página de descarga.

La interfaz puede variar según la versión y el idioma. En los pasos siguientes identificaremos las funciones por su nombre, sin depender de un atajo específico del sistema operativo.

Necesitarás también Docker con el complemento Docker Compose y un puerto local 54329 disponible. En Docker Engine, utiliza una versión actual: la documentación advierte de diferencias de aislamiento de puertos enlazados a localhost en versiones anteriores a la 28. La publicación de puertos de Docker explica ese alcance.

Preparar PostgreSQL con datos ficticios

Crea una carpeta independiente para el laboratorio:

mkdir -p dbeaver-lab/init
cd dbeaver-lab

Dentro, guarda este archivo como compose.yaml:

name: uncodigo-dbeaver-lab

services:
  postgres:
    image: postgres:17
    environment:
      POSTGRES_DB: tienda_lab
      POSTGRES_USER: lab_admin
      POSTGRES_PASSWORD: solo-lab-admin-no-reutilizar
    ports:
      - '127.0.0.1:54329:5432'
    volumes:
      - datos:/var/lib/postgresql/data
      - ./init:/docker-entrypoint-initdb.d:ro
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U lab_admin -d tienda_lab']
      interval: 3s
      timeout: 3s
      retries: 20

volumes:
  datos:

Publicamos el puerto únicamente en la interfaz local. Las contraseñas son deliberadamente ficticias y exclusivas de este entorno desechable; no reutilices este archivo como configuración productiva. El laboratorio no configura TLS.

La imagen oficial utiliza POSTGRES_USER para crear un usuario con privilegios elevados durante la inicialización. Por eso crearemos otro usuario para DBeaver, con permisos sobre las tablas del ejercicio. El directorio de datos y los scripts iniciales siguen las convenciones de la imagen oficial de PostgreSQL para la versión 17.

Guarda lo siguiente como init/01-tienda.sql:

CREATE SCHEMA tienda;

CREATE TABLE tienda.categorias (
  id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  nombre text NOT NULL UNIQUE
);

CREATE TABLE tienda.productos (
  id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  categoria_id integer NOT NULL REFERENCES tienda.categorias(id),
  nombre text NOT NULL,
  precio numeric(10, 2) NOT NULL CHECK (precio >= 0),
  stock integer NOT NULL CHECK (stock >= 0)
);

CREATE INDEX productos_categoria_idx
  ON tienda.productos(categoria_id);

INSERT INTO tienda.categorias (nombre)
VALUES ('Papelería'), ('Escritorio');

INSERT INTO tienda.productos (categoria_id, nombre, precio, stock)
VALUES
  (1, 'Cuaderno de prueba', 4.50, 20),
  (1, 'Lápiz de prueba', 1.20, 50),
  (2, 'Lámpara de prueba', 25.00, 8),
  (2, 'Organizador de prueba', 12.00, 10);

CREATE ROLE lab_editor LOGIN PASSWORD 'solo-lab-editor-no-reutilizar';

GRANT CONNECT ON DATABASE tienda_lab TO lab_editor;
GRANT USAGE ON SCHEMA tienda TO lab_editor;

GRANT SELECT, INSERT, UPDATE, DELETE
  ON ALL TABLES IN SCHEMA tienda TO lab_editor;

GRANT USAGE, SELECT
  ON ALL SEQUENCES IN SCHEMA tienda TO lab_editor;

Un esquema agrupa objetos dentro de una base de datos. Aquí tienda contiene dos tablas; categoria_id relaciona cada producto con una categoría mediante una clave foránea. La clave primaria id identifica cada fila y facilitará su edición inequívoca.

Los permisos se conceden sobre objetos existentes. No autorizan automáticamente las tablas que se creen en el futuro. Además, permitir DELETE sobre estas tablas sigue permitiendo borrar sus filas: este usuario sirve para practicar edición, no como perfil de consulta de producción. Los privilegios de PostgreSQL se aplican en el servidor, independientemente del cliente utilizado.

Inicia el servicio:

docker compose up -d --wait
docker compose ps

Los scripts de inicialización solo se ejecutan cuando el directorio de datos está vacío. Si ya existe el volumen, cambiar el SQL o las variables del Compose no reinicializa la base.

Crear y comprobar la conexión

En DBeaver, abre New Database Connection, elige PostgreSQL y completa:

Si solicita descargar el controlador PostgreSQL, revisa la descarga propuesta por el gestor de controladores. Usa Test Connection y después Finish. Identifica la conexión con un nombre como LOCAL · tienda_lab para distinguirla de otros entornos. La guía de conexiones detalla el asistente y sus opciones.

En el editor SQL asociado a esa conexión, ejecuta:

SELECT current_database(), current_user;

El resultado debe indicar tienda_lab y lab_editor. Comprobarlo antes de una modificación ayuda a detectar una pestaña conectada al entorno equivocado.

Si la conexión falla, revisa primero el estado del contenedor, el puerto publicado y los valores introducidos. No cambies reglas de autenticación ni desactives validaciones de una conexión remota para resolver por ensayo y error un problema local.

Explorar esquemas, tablas e índices

En el panel de conexiones —también denominado Database Navigator, según la versión— despliega la base y busca Schemas → tienda → Tables. Si no aparece un objeto recién creado, actualiza el árbol. La documentación del navegador describe su organización.

Abre productos y observa sus propiedades: columnas, tipos, clave primaria, clave foránea e índices. La pestaña de datos muestra registros; la definición SQL o DDL describe cómo está construido el objeto. DDL, Data Definition Language, es el conjunto de instrucciones para definir estructuras, como CREATE TABLE.

El editor de objetos permite navegar entre propiedades y datos. Inspeccionar una definición no obliga a modificarla: en un proyecto compartido, los cambios de estructura deberían quedar representados por migraciones revisables, no solo por clics en una sesión individual.

También puedes consultar metadatos mediante SQL:

SELECT column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_schema = 'tienda'
  AND table_name = 'productos'
ORDER BY ordinal_position;

information_schema.columns entrega información de las columnas accesibles al usuario. Para los índices PostgreSQL:

SELECT indexname, indexdef
FROM pg_indexes
WHERE schemaname = 'tienda'
  AND tablename = 'productos'
ORDER BY indexname;

En el laboratorio aparecen productos_categoria_idx y productos_pkey. La vista pg_indexes muestra sus definiciones. Que exista un índice no implica que una consulta vaya a utilizarlo, especialmente con cuatro filas: esa decisión se estudia con planes de ejecución, como explicamos en cuándo ayudan los índices en PostgreSQL.

Consultar datos desde el editor SQL

Abre un script SQL sobre la conexión del laboratorio. DBeaver distingue entre ejecutar una sentencia —o el texto seleccionado— y ejecutar un script completo. Comprueba qué vas a enviar, especialmente si el archivo combina consultas y modificaciones. La documentación de ejecución SQL describe ambas acciones.

Ejecuta esta consulta:

SELECT
  p.id,
  p.nombre,
  c.nombre AS categoria,
  p.precio,
  p.stock,
  p.precio * p.stock AS valor_stock
FROM tienda.productos AS p
JOIN tienda.categorias AS c ON c.id = p.categoria_id
ORDER BY p.id;

El JOIN permite mostrar el nombre de la categoría sin duplicarlo en cada producto. Puedes profundizar en esa relación con la guía de tipos de JOIN en SQL.

Estos son los valores obtenidos al ejecutar la consulta contra PostgreSQL en el laboratorio:

La cuadrícula permite inspeccionar valores, pero no sustituye el significado de la consulta. Por ejemplo, para obtener un resumen por categoría, cambiamos el SQL:

SELECT
  c.nombre AS categoria,
  COUNT(*) AS productos,
  SUM(p.precio * p.stock) AS valor_stock
FROM tienda.productos AS p
JOIN tienda.categorias AS c ON c.id = p.categoria_id
GROUP BY c.id, c.nombre
ORDER BY c.nombre;

El resultado es Escritorio: 2 productos, 320.00 y Papelería: 2 productos, 150.00. Se trata del valor del inventario, no de ventas realizadas.

Editar registros: guardar no siempre es confirmar

Para practicar edición, abre los datos de la tabla base tienda.productos. Evita empezar por el resultado agregado anterior: una fila que representa varios productos no corresponde a un único registro actualizable.

Antes de editar, selecciona el modo Manual commit para esa conexión y comprueba que esté activo. Filtra el producto con id = 1, cambia stock de 20 a 19 y revisa el cambio pendiente. Al guardar la cuadrícula, DBeaver envía la modificación a la base. En modo manual, todavía queda pendiente confirmarla mediante Commit o descartarla mediante Rollback.

Usa Rollback y actualiza los datos: el stock debe volver a 20. La acción de cancelar una edición aún no enviada en la cuadrícula es distinta de revertir una transacción que ya ejecutó SQL. La guía de edición de datos explica cómo revisar y guardar cambios.

La existencia de una clave primaria facilita identificar la fila. Si un resultado no es editable o DBeaver solicita una clave virtual, no elijas columnas arbitrarias: primero comprueba qué hace única a cada fila. Los permisos de escritura también deben existir en PostgreSQL.

Entender las transacciones con SQL

Una transacción agrupa operaciones que se confirman juntas o se descartan. Auto-commit confirma las sentencias automáticamente; Manual commit mantiene cambios pendientes hasta una decisión explícita. No puedes recuperar mediante ROLLBACK una modificación que ya fue confirmada. La guía de modos de DBeaver desarrolla esta diferencia.

Para observar el mecanismo directamente, termina cualquier transacción pendiente en DBeaver y abre una sesión de psql, el cliente de terminal de PostgreSQL:

docker compose exec postgres psql \
  -h 127.0.0.1 -U lab_editor -d tienda_lab -W

Introduce la contraseña ficticia de lab_editor cuando la solicite. En esta sesión delimitaremos la transacción mediante SQL; en DBeaver, el modo manual y los botones de confirmación permiten controlar ese mismo mecanismo. Ejecuta las sentencias paso a paso:

BEGIN;

UPDATE tienda.productos
SET stock = stock - 1
WHERE id = 1
  AND stock > 0
RETURNING id, nombre, stock;

RETURNING muestra el valor modificado: si partimos de 20, devuelve 19. Ahora descarta esa modificación:

ROLLBACK;

SELECT id, stock
FROM tienda.productos
WHERE id = 1;

El stock vuelve a 20. Repite la operación, pero esta vez confírmala:

BEGIN;

UPDATE tienda.productos
SET stock = stock - 1
WHERE id = 1
  AND stock > 0
RETURNING id, nombre, stock;

COMMIT;

SELECT id, stock
FROM tienda.productos
WHERE id = 1;

Ahora el resultado es 19. Estos dos comportamientos se comprobaron con PostgreSQL en el laboratorio; el tutorial oficial de transacciones explica la atomicidad y la visibilidad de los cambios.

Sal de psql con \q después de terminar la transacción. Si consultas la tabla en DBeaver, actualiza el resultado para ver el cambio confirmado.

La transacción pertenece a una sesión. No asumas que otra pestaña, editor o conexión comparte la misma: un ROLLBACK en otra sesión no cancela los cambios de la primera. Tampoco dejes una transacción de escritura abierta mientras haces otra tarea; puede mantener bloqueos y dificultar el trabajo de otras sesiones.

Exportar resultados sin confundirlos con un respaldo

Ejecuta una consulta que seleccione únicamente los datos necesarios:

SELECT id, nombre, precio, stock
FROM tienda.productos
ORDER BY id;

Desde el resultado, abre Export data, selecciona CSV y revisa el archivo de destino, la codificación, el delimitador y la inclusión de cabeceras. Comprueba también el alcance: exportar filas ya recuperadas y ejecutar la consulta para obtener el resultado completo no son necesariamente la misma operación. La documentación de exportación explica las opciones disponibles.

La descarga queda en el equipo donde ejecutas el cliente. En una base real, esa copia puede necesitar controles de acceso y una política de eliminación propios. Exportar un CSV tampoco conserva por sí solo el esquema, las restricciones, los permisos y todos los elementos necesarios para restaurar una base de datos.

Credenciales y precauciones para producción

Las contraseñas del ejercicio son públicas y ficticias. Para conexiones reales, utiliza cuentas individuales o identidades autorizadas, separadas por entorno. Si solo necesitas investigar datos, empieza con permisos de lectura concedidos en el servidor.

Guardar una contraseña en un cliente implica confiar también en la seguridad del equipo y de su perfil de usuario. No incluyas archivos del workspace, configuraciones exportadas con credenciales ni resultados sensibles en Git. No pegues contraseñas en scripts SQL que después compartirás. Tampoco atribuyas a Community la función comercial Master Password mencionada antes.

Para una conexión remota, configura TLS de acuerdo con el motor y el controlador, validando el certificado y la identidad del servidor. Una conexión cifrada con verificación desactivada no ofrece las mismas garantías. DBeaver documenta los parámetros SSL/TLS por conexión; sus opciones dependen del controlador.

Antes de modificar datos productivos:

• Comprueba servidor, base y usuario; un nombre o color distintivo ayuda, pero no impide una operación.
• Revisa el WHERE, los registros objetivo y el número de filas afectadas. Una consulta previa ayuda a revisar el alcance, aunque no evita cambios concurrentes.
• Define cómo confirmar o revertir la operación y mantén las transacciones breves.
• Usa un procedimiento revisable para cambios de esquema o modificaciones masivas, con respaldo y recuperación probados cuando correspondan.
• Limita consultas y exportaciones: incluso un usuario de lectura puede consumir recursos o copiar información sensible.

La interfaz facilita operar; los permisos, el proceso de revisión y los controles del servidor determinan el alcance real de esas operaciones.

DBeaver, pgAdmin o una herramienta del motor

DBeaver resulta práctico cuando alternas entre motores y quieres una experiencia común para explorar y consultar. Esa generalidad tiene un costo: hay más opciones visibles y algunas tareas específicas se entienden mejor desde las herramientas del propio motor.

pgAdmin está orientado a PostgreSQL y ofrece funciones de consulta y administración centradas en ese ecosistema. Si todo tu trabajo gira alrededor de PostgreSQL, puede encajar mejor con tus necesidades.

MySQL Workbench concentra sus funciones de modelado, desarrollo SQL y administración en MySQL. Los clientes de terminal, como psql, siguen siendo útiles para scripts y procesos reproducibles. Ninguna elección elimina la necesidad de conocer el SQL y los permisos del servidor.

Terminar el laboratorio y conservar lo útil

Cierra la conexión en DBeaver y detén los recursos desde la carpeta del ejercicio:

docker compose down

Eso conserva el volumen. Si ya no necesitas los datos ficticios, puedes eliminarlos junto con los recursos del laboratorio:

docker compose down -v

La segunda orden borra el volumen de este proyecto. Al volver a iniciarlo se ejecutarán otra vez los scripts iniciales. Conserva compose.yaml, el SQL de preparación y tus consultas si quieres repetir el ejercicio.

La mejor forma de incorporar DBeaver al trabajo diario es empezar por observar: identificar la conexión, entender la estructura y escribir consultas acotadas. Después puedes editar con una distinción clara entre lo que está pendiente en la interfaz, lo que ya ejecutó el servidor y lo que finalmente quedó confirmado.

Referencias

• DBeaver Community: descripción y motores compatibles.
• Descargas oficiales de Community.
• DBeaver: creación de conexiones.
• DBeaver: editor de objetos.
• DBeaver: ejecución de SQL.
• DBeaver: modos Auto-commit y Manual commit.
• DBeaver: exportación de datos.
• PostgreSQL: transacciones.
• PostgreSQL: privilegios.
• Imagen oficial PostgreSQL para Docker.