22.000 estrellas, una insignia de «25 MB» y 443 MB de agentes Java: auditoría del cliente de bases de datos DBX

Hay un cliente de bases de datos llamado DBX que ha sido imposible de esquivar desde la primavera. Su repositorio de GitHub se define como «cliente de bases de datos multiplataforma ligero de 25 MB para más de 100 bases de datos». Su web, en la cabecera, dice «¡25 MB para gestionar más de 100 bases de datos!». Tiene 21.998 estrellas, 2.087 forks y 306 versiones publicadas en 154 días: dos al día.

Esta auditoría ha consistido en hacer una sola cosa: leer los objetos que el proyecto realmente distribuye. No el README ni las insignias, sino los instaladores, la imagen de contenedor, el manifiesto de controladores legible por máquina que la propia aplicación descarga en tiempo de ejecución, las notas de versión y el middleware de autenticación. Casi todas las cifras que siguen se pueden reproducir en una tarde con curl y un token de GitHub. Ese es el punto: ninguna requiere acceso privilegiado ni revisión de código fuente, y varias contradicen la parte más visible del embudo.

El resumen: DBX es una aplicación Tauri interesante y bien construida, con un registro de cambios inusualmente honesto y un fallo de seguridad crítico en su pasado reciente. También está envuelta en una pila de afirmaciones que sus propios artefactos no sostienen, y en un contador de descargas que es un 80% tráfico de máquinas. Las dos cosas son ciertas a la vez, y la segunda importa si vas a elegir herramienta para un equipo.

La pila de afirmaciones, comprobada

Qué describe realmente el «25 MB»

El número no está inventado: simplemente trabaja mucho. Descargar el .deb de la v0.6.28 (41.109.138 bytes) y descomprimirlo deja un único binario, /usr/bin/dbx, de 88.861.984 bytes (84,74 MiB), mientras que los metadatos del paquete declaran un Installed-Size de 86.905 KB. El .deb ocupa 39,20 MiB en tránsito porque comprime bien; lo que acaba en tu disco triplica la cifra anunciada.

Este es el panorama completo de escritorio para la versión actual:

Solo uno de ellos pesa 25 MB. De la tabla se deducen dos cosas. La primera es que el instalador para Windows en ARM de ese día se queda en 25,70 MB decimales / 24,51 MiB, así que el titular no es una mentira tanto como una selección: es el mínimo de los 33 artefactos publicados con la v0.6.28, presentado como el tamaño del producto. La segunda es que cuando la web dice «~25 MB desktop installer», el matiz hace trabajo real, y en cuanto sales de Windows te dejas el matiz atrás.

Las variantes sin conexión son donde aparece la escala honesta. Los paquetes «intranet» de Windows 10/11 se publican con 173,46 MiB y 231,75 MiB porque incorporan el runtime WebView2, y el tren de versiones también incluye dbx-agents-offline-windows-x64.zip con 661,02 MB, dbx-agents-offline-macos-x64.zip con 663,7 MB y dbx-agents-offline-macos-aarch64.zip con 658,9 MB. No son la aplicación: son el paquete de controladores.

El número ha derivado, en la misma página

Esta es la parte que me hizo dejar de confiar en el titular en lugar de matizarlo. La web oficial en inglés, en una sola página, muestra ahora mismo todo esto:

• Título y hero: «¡25 MB para gestionar más de 100 bases de datos!»
• Tarjeta: «~25 MB desktop installer»
• Testimonio (Zhihu, junio de 2026): «Un paquete de 15 MB que incluye más de 40 bases de datos…»
• Testimonio (Medium, mayo de 2026): «La cifra de 15 MB no es marketing. Tauri 2 no incrusta Chromium…»
• Testimonio (xiaoz.org, mayo de 2026): «una potente herramienta de código abierto por debajo de 20 MB»
• Testimonio (X, agosto de 2026): «una herramienta de código abierto de solo 20 MB que incluye más de 80 bases de datos»
• Testimonio (HelloGitHub, número 122): «compatible con más de 40 bases de datos»

Es decir, el tamaño oscila entre 15, 20 y 25 MB, y el número de motores entre 40+, 80+ y 100+, sin que ninguna de esas cifras esté marcada como histórica. El propio artículo de lanzamiento del autor en DEV Community, del 2 de mayo de 2026, se titula «DBX: un cliente de bases de datos de código abierto de 15 MB para más de 17 bases de datos (construido con Tauri)» y afirma que «el instalador ocupa solo ~15 MB». Una reseña independiente publicada el 16 de julio de 2026 por Oleksandr Korol describe «más de 60 bases de datos manteniendo la aplicación en torno a 20 MB».

Eso es una deriva de seis meses desde 15 MB/17 motores hasta 25 MB/100 motores, con una docena de cifras intermedias, y todas siguen mostrándose como marketing vigente. Aquí no hay fraude: el producto realmente creció en capacidades y adelgazó en marketing. Pero un número que puede ser 15, 20 o 25 según el párrafo que leas no es una especificación, es un eslogan.

Para calibrar, la comparación que sí hace el README es justa. DBeaver Community 26.2.1 publica un .deb de Linux de 121,1 MB, una imagen de disco de macOS ARM de 117,0 MB y un instalador de Windows de 111,2 MB. El .deb de 39,20 MiB de DBX es de verdad alrededor de un tercio, y Tauri evita incrustar Chromium: el .deb depende de libwebkit2gtk-4.1-0, libgtk-3-0 y libappindicator3-1 del sistema. «Un tercio de la descarga de DBeaver» es defendible, comprobable y aburrido. «25 MB» no es ninguna de las tres cosas.

100 bases de datos, descompuestas

El «100+» resulta ser exactamente 100 en la marquesina del propio sitio, y merece la pena leer la lista como conjunto y no como recuento:

• 9 entradas no son bases de datos. Etcd, ZooKeeper, Pulsar, Kafka, RocketMQ, RabbitMQ, MQTT, Nacos y Consul son colas de mensajes y almacenes de configuración o descubrimiento de servicios. DBX les da consolas de primera clase, lo cual es una función real, pero contarlos infla la cifra de «motores de bases de datos».
• 2 entradas son variantes de versión de otra entrada. «Ignite 3» e «InfluxDB 3» se cuentan aparte de Ignite e InfluxDB.
• 1 entrada es un alias de producto. InterSystems Caché e InterSystems IRIS son la misma línea de producto, listada dos veces.
• 1 entrada es un protocolo, no un producto. «JDBC» es el cajón de sastre para cualquier cosa con controlador Java.

Quitando todo eso, «más de 100 motores» son 87 motores de datos distintos, que sigue siendo una cifra extraordinaria y muy superior a lo que cubre cualquier cliente gráfico occidental recién instalado. Lo interesante es la composición: 27 de los 100 nombres son motores del mercado chino (Dameng, openGauss, GaussDB, KingbaseES, OceanBase, TDSQL, PolarDB, GreatSQL, GoldenDB, YashanDB, GBase, XuguDB, Vastbase, UXDB, HighGo, SelectDB, Doris, TDengine, KWDB, ArgoDB, Transwarp Inceptor, Kylin, OSCAR, SunDB, Kyuubi, Cloudberry, OpenTenBase), 29 si cuentas TiDB y StarRocks. Ningún cliente occidental se acerca a esa cobertura, y es la señal más clara de para quién está construido DBX.

Siete controladores nativos y 54 agentes Java

La frase del README «Agent-based profiles extend DBX to H2, Snowflake, Trino…» trabaja más de lo que parece. En el repositorio hay exactamente siete crates de controlador nativos en Rust: dbx-driver-mysql, -postgres, -redis, -mongodb, -elasticsearch, -sqlserver y -sqlite-worker. Todo lo demás pasa por agents/, que contiene 53 directorios de controlador (Java y Go) y genera un tren de versiones aparte.

El propio manifiesto de ejecución de la aplicación lo deja explícito. agent-registry.json —un archivo de 57.350 bytes adjunto a la versión agents-v0.2.125 que la aplicación consulta para saber qué descargar— tiene dos claves de primer nivel: jres y drivers. Lista 54 controladores, y los 54 declaran "jre": "21". Ninguno funciona sin el runtime. El mismo archivo fija ese runtime: una compilación propia de OpenJDK, 21.0.12+kerberos.ec.2, distribuida por plataforma entre 30,5 MB (Windows ARM64) y 34,8 MB (Linux x64).

Sumando los 54 paquetes de agente salen 408,1 MB; con un JRE, la capacidad completa de «más de 100 bases de datos» cuesta 443,0 MB de descargas bajo demanda por encima del binario principal de 84,74 MiB. El extremo pesado de la lista es ilustrativo:

Dos conclusiones, y quiero ser justo con las dos. Primero, la arquitectura es defendible: enviar un JRE de 34,8 MB y un agente Snowflake de 67,9 MB a todos los usuarios, los usen o no, sería peor. Descargarlo bajo demanda es la decisión correcta, y el registro de DBX es inusualmente transparente al respecto: puedes leer el manifiesto antes de confiar en él, con hashes SHA-256 incluidos. Segundo, la frase de marketing «No Java JRE. No Python venv. No bundled Chromium. DBX ships as a single small binary» no es cierta respecto al producto. Es cierta respecto al instalador, y solo para los siete motores nativos. Para la distribución Docker ni eso: deploy/Dockerfile instala openjdk-17-jre-headless y define DBX_JAVA_BIN=/usr/bin/java.

Así que «ligero» aquí significa «pequeño hasta que lo usas». Para un uso diario con MySQL, PostgreSQL y Redis, DBX pesa lo que dice. Para quien necesita Snowflake y Kafka a la vez, la cifra real se acerca a medio gigabyte de runtimes descargados después de instalar, y si trabajas sin conexión, ahí están los paquetes de agentes de 661 MB.

El capítulo de seguridad: CVE-2026-55642

El 20 de agosto de 2026, con GitHub como CNA, se publicó una vulnerabilidad crítica para DBX: CVE-2026-55642, CVSS 3.1 9,8, CWE-306 (falta de autenticación para una función crítica). El rango afectado es todo lo anterior a la 0.5.51.

El mecanismo está descrito en el aviso y coincide con el código público. En crates/dbx-web/src/auth.rs, el auth_middleware dejaba pasar toda petición protegida a la cadena de manejadores siempre que password_hash fuese None. Un despliegue nuevo llega exactamente a ese estado cuando DBX_PASSWORD no está definida y todavía no hay contraseña almacenada, y crates/dbx-web/src/main.rs escuchaba por defecto en todas las interfaces, puerto 4224. El resultado: un cliente de red sin autenticar podía llamar a /api/connection/connect y /api/query/execute y ejecutar SQL arbitrario con las credenciales que DBX ya tenía configuradas. La aplicación de escritorio no estaba afectada porque solo escucha en loopback.

Hay dos cosas que un futuro usuario debería mirar: la forma del fallo y la forma de la divulgación. El fallo no es un accidente de seguridad de memoria; es un valor por defecto fail-open en una comprobación de autenticación: la falta de configuración se trató como motivo para saltarse la autenticación en vez de como motivo para negarse a servir. Es la manera más común de que una herramienta de desarrollo autoalojada acabe comprometida, y el arreglo es el del manual: negarse.

La divulgación también se partió en dos. La corrección llegó en la v0.5.51, el 8 de julio de 2026, y sus notas la describen en chino como una corrección del MCP web —«Web 部署的 MCP 调用现在需要认证，避免未授权访问»—, atribuida a un colaborador y cerrando la incidencia #2887. Sin CVE, sin aviso y sin ningún encuadre de seguridad en ese momento. El CVE y el aviso GHSA-rqp4-8fxh-22vh aparecieron seis semanas después, el 20 de agosto. Quien se guiara solo por las notas de versión de julio no tuvo ninguna señal el 8 de julio de que hubiera pasado algo relevante para su seguridad.

He leído el auth.rs actual en main para comprobar qué hace hoy un despliegue nuevo, y la corrección es real y razonablemente completa. Solo auth/login, auth/setup y auth/check son accesibles sin sesión; todo lo demás devuelve 401 mientras password_hash sea None, con una respuesta explícita setup_required en el login. Las contraseñas se guardan como hashes Argon2, el login tiene límite de intentos (cinco, con bloqueo de 60 segundos), las sesiones son cookies HttpOnly; SameSite=Lax con Secure opcional vía DBX_WEB_COOKIE_SECURE=1, y change-password exige sesión, de modo que no puede usarse como oráculo de contraseñas sin autenticar.

Quedan dos matices tras el arreglo. El servicio web sigue escuchando en todas las interfaces por defecto —el comentario en main.rs lo dice literalmente y ofrece DBX_BIND_ADDR=127.0.0.1 para quien lo ponga detrás de un proxy inverso local— y el deploy/docker-compose.release.yml que se distribuye publica 4224:4224 sin definir la variable de contraseña, algo aceptable solo porque una instancia nueva ahora lo rechaza todo hasta completar la configuración. Además, DBX_PASSWORD sin definir sigue siendo el estado por defecto en el primer arranque, y nada en el compose te lo advierte.

Si autoalojas DBX hoy, el mínimo es: fijar una versión ≥ 0.6.28; definir DBX_PASSWORD antes del primer arranque; definir DBX_BIND_ADDR=127.0.0.1 salvo que haya un proxy inverso autenticado; respaldar ${DBX_DATA_DIR}/.dbx/secret.key junto con dbx.db (la documentación es explícita: la clave no se puede rotar mientras haya datos cifrados en uso, y copiar solo dbx.db no sirve porque las claves de plataforma no viajan); y usar cuentas de base de datos con privilegios mínimos. Las versiones posteriores añadieron refuerzos que conviene tener: validación de mismo origen en el upgrade WebSocket del pub/sub de Redis, rechazo de complementos sin firma por defecto y cambios de contraseña que invalidan todas las sesiones activas.

La insignia de descargas es un 80% pings del autoactualizador

El README muestra una insignia de descargas con 2,8 M. Esto es de qué está hecha. Leyendo los contadores por artefacto del propio GitHub en las 306 versiones, del 29 de abril al 29 de septiembre de 2026, salen 2.783.550 descargas totales: de ahí viene el 2,8 M. De ese total, 2.237.662 (el 80,4%) son latest.json, el manifiesto del autoactualizador de Tauri, un archivo de máquina de 18,4 KB que cada copia instalada consulta para buscar actualizaciones. El repositorio incluso incluye tauri-plugin-updater vendorizado, así que no hay ambigüedad sobre el mecanismo.

Descargas reales de artefactos: 545.888 en toda la historia del proyecto, y esa cifra todavía cuenta archivos .sig, sumas .sha256 y el conjunto completo de instaladores de cada versión, que las instalaciones longevas vuelven a descargar en cada actualización.

La clasificación por artefacto es lo más revelador de esta auditoría:

De ahí salen dos cosas. El artefacto real más descargado de todo el proyecto es el complemento JDBC, justo el componente que la web dice que DBX no necesita («Native Rust drivers, no JDBC runtime»). Y el tarball del JRE supera a cualquier instalador individual de la aplicación salvo los dos más recientes, lo que confirma empíricamente lo que insinuaba el registro: la vía de los agentes Java no es un caso límite, es el caballo de batalla.

Hay además una discrepancia entre proveedores que conviene conocer. Para el mismo repositorio y la misma métrica, shields.io informa ahora de 798.000 mientras la insignia del README informa de 2,8 M: un factor 3,5 entre dos insignias de «descargas». No he conseguido reproducir las 798.000 desde la API de GitHub con ningún corte, y la cifra de shields.io para la última versión (6.300) sí coincide con el contador de GitHub para la v0.6.28 (6.343 en el momento de escribir), así que la discrepancia es específica del total. No sé qué proveedor está «equivocado»; lo que sí puedo decir es que una métrica que tres proveedores reportan como 798.000, 2,8 M y 545.000 reales no es una métrica para citar en un pliego de compra.

Si quieres una estimación de base instalada, no uses ninguna de esas cifras. Usa el contador del manifiesto de la versión más reciente: el latest.json de la v0.6.28 se había descargado 5.231 veces en unas ocho horas desde su publicación, mientras que su instalador de Windows x64 se había descargado 435 veces. Sea cual sea la población real, el canal de comprobación de actualizaciones está un orden de magnitud más ocupado que el canal de descarga: eso es lo que cabe esperar de un parque de instalaciones existentes que consulta, no de 2,8 millones de personas probando DBX.

832 instalaciones por Homebrew frente a 21.998 estrellas

Las estrellas son la señal de adopción menos fiable del código abierto, así que aquí va una medición que no es un recuento de estrellas. Homebrew publica analíticas anonimizadas de instalación y, para la ventana de 30 días entre el 30 de agosto y el 29 de septiembre de 2026 (9.743 casks, 1.098.246 eventos registrados), los clientes de bases de datos se ordenan así:

DBX está en el 2% mejor de casks de Homebrew (puesto 196 de 9.743), lo cual está genuinamente bien para un proyecto de cinco meses y no es la historia que cuenta su número de estrellas. Compárense las dos proporciones: DBX tiene el 42,4% de las estrellas de DBeaver (21.998 frente a 51.922) y el 15,9% de sus instalaciones en macOS. Su ratio de estrellas por instalación es unas 2,7 veces el de DBeaver. Esa brecha es la forma normal de un proyecto que fue tendencia en GitHub China en agosto (Trendshift registra el puesto 2 en GitHub Trending, además de insignias de repositorio del día, de la semana y del mes): las estrellas son una métrica de descubrimiento, no de adopción, y DBX es el caso de manual.

El resto del ecosistema está mezclado, pero en general mejor de lo que sugieren las insignias:

• Docker Hub: 152.059 descargas de t8y2/dbx y 2 estrellas. Las descargas son reales; los 138,42 MiB de la imagen también.
• npm (últimos 30 días): @dbx-app/mcp-server 42.185; @dbx-app/plugin-cli 5.241; @dbx-app/cli 4.646. Los recuentos de npm incluyen CI y réplicas, así que tómalos como cota superior, pero que el paquete más instalado sea el servidor MCP encaja con la función que las reseñas sí elogian.
• Homebrew, WinGet y AUR: los tres presentes. El cask de Homebrew está en el tap oficial homebrew/cask con autobump activado, y t8y2.DBX existe en microsoft/winget-pkgs con directorios de versión hasta la 0.6.28. Es mejor cobertura de empaquetado que la de la mayoría de proyectos con el doble de edad.
• Flathub: ausente. com.dbxio.dbx devuelve «App not found» en la API de Flathub. El README, en su lugar, indica a los usuarios de Linux que añadan un repositorio remoto de terceros llamado FlatPark (dl.flatpark.org, que se describe como «Yet another Flatpak hub»). Es decir, la instrucción de instalación apunta a una fuente de paquetes no estándar para una herramienta que va a custodiar credenciales de bases de datos de producción.
• AUR: dos paquetes, dbx y dbx-bin. El segundo declara licencia MIT cuando el proyecto original es Apache-2.0. Los errores de empaquetado de terceros son habituales, pero un campo de licencia incorrecto en el paquete que instalará la mayoría de usuarios de Arch merece conocerse.

306 versiones en 154 días

Entre el 29 de abril de 2026 (creación del repositorio) y el 29 de septiembre, el proyecto publicó 306 versiones: 1,99 al día. Llegan en tres trenes: la aplicación de escritorio (v0.6.x, 31–33 artefactos por versión), los agentes Java/Go (agents-v0.2.x, 146–153 artefactos por versión, casi a diario) y los paquetes de CLI y MCP (packages-v0.4.x, 14 artefactos). La aplicación pasó de la v0.6.20, el 22 de septiembre, a la v0.6.28, el 29 de septiembre: nueve versiones en ocho días.

Esta velocidad es la mejor y la peor propiedad del proyecto. Es la razón de que cubra 87 motores y corrija cosas en días; también es la razón de que «fija una versión» no sea opcional, de que los 306 cuerpos de versión sean el único registro de cambios fiable y de que el arreglo de seguridad anterior pudiera salir como un punto de una nota de 3.233 caracteres en chino. Si lo despliegas en un equipo, presupuesta leer notas de versión, no estabilidad.

Para quién está construido

Sigue el dinero y los enlaces de comunidad, y el cuadro es inequívoco. La raíz del sitio sirve chino (zh-CN); la web en inglés es la traducción. Los enlaces de comunidad son grupos de QQ, WeChat y Feishu, además de Discord. Las descargas de Docker se replican en docker.cnb.cool/dbxio.com/dbx para usuarios dentro de China. El README lleva ocho tarjetas de patrocinador y dos de socio, la mayoría con enlaces de referido: RainYun, TrustAsia (que firma las compilaciones de Windows), Jalapeño Cloud, AICodeMirror, HuaLongAI, AstraFlow de UCloud, Atlas Cloud, Qiniu Cloud, más las integraciones con 1Panel y Easysearch.

Uno de ellos merece una advertencia. La tarjeta de AICodeMirror anuncia acceso revendido a Claude Code / Codex / Gemini «desde el 38% / 2% / 9% del precio de lista». Vender acceso de API revendido y con descuento a suscripciones de primera parte para programación con IA es una zona gris bien conocida, y es un patrocinio, no una dependencia técnica. Pero ahora es una fila del README de una herramienta que apuntarías a bases de datos de producción, y conviene ponderarlo igual que se ponderaría un anuncio de VPN en el repositorio de una herramienta de seguridad.

Nada de esto convierte a DBX en una mala herramienta. Lo convierte en un producto con prioridad china y una página de GitHub orientada al inglés, lo que explica tanto su lista de motores (más de 27 bases de datos chinas que ningún cliente occidental soporta) como su estructura de comunidad. Si trabajas con Dameng, openGauss, KingbaseES u OceanBase, la competencia de DBX no es DBeaver: es una herramienta local de pago.

Lo que aquí sí es bueno

Una auditoría que solo cuenta problemas no es una auditoría, y este proyecto tiene ingeniería real que el marketing no debería tapar:

• Tauri 2, sin Chromium incrustado, verificado. El .deb depende de libwebkit2gtk-4.1-0 del sistema; no hay carga de tipo Electron. Es una ventaja arquitectónica real frente a casi toda su competencia.
• Apache-2.0, con una tienda de complementos que publica su infraestructura de seguridad. t8y2/dbx-store incluye signing-keys.json, revoked.json, un directorio de publicadores, esquemas JSON y un SECURITY.md; la v0.6.28 fue más allá y rechaza complementos sin firma por defecto.
• Versiones firmadas y con sumas de comprobación. Cada artefacto tiene SHA-256, varios tienen firmas .sig separadas y las compilaciones de Windows pasan por un proveedor de firma de código anunciado como patrocinador.
• El registro de agentes es público y legible por máquina. Poder leer exactamente qué compilación de JRE y qué versión de JAR de agente vas a descargar es más transparencia de la que ofrecen casi todos los clientes.
• Un registro de cambios real y detallado. 306 notas de versión con atribución de colaboradores y enlaces a PR; las de la v0.6.28 acreditan por nombre a más de diez colaboradores externos.
• Cobertura amplia de motores. 87 motores distintos, incluyendo series temporales, vectores y motores de búsqueda, además de colas de mensajes y descubrimiento de servicios en la misma ventana.
• El servidor MCP es un binario independiente en un paquete aparte (@dbx-app/mcp-server, en Rust, precompilado para cinco plataformas, sin necesidad de Node) con un modelo de políticas de solo lectura, escritura segura y acceso total. El README dice con claridad que instalar la aplicación no instala el ejecutable MCP, y avisa de que las compilaciones portables de Windows necesitan DBX_DATA_DIR: documentación honesta de un borde incómodo.
• Más de 305 colaboradores y un SDK de complementos. Sea lo que sea lo demás, esto no es un espectáculo de una sola persona con presupuesto de marketing.

Tabla de decisión práctica

Preguntas frecuentes

¿Es falsa la afirmación de los «25 MB»? No es falsa, es el mínimo. De los 33 artefactos de la v0.6.28, el instalador para Windows en ARM son 24,51 MiB (25,70 MB): el único que redondea a 25 MB. Windows x64 son 26,74 MiB, el .deb de Linux instala 84,87 MiB, el AppImage ocupa 110,68 MiB y la imagen Docker 138,42 MiB. La web lo matiza como «~25 MB desktop installer».

¿De verdad DBX no necesita Java? Para sus siete controladores nativos en Rust, sí. Para todo lo demás, no: agent-registry.json lista 54 controladores que requieren un OpenJDK propio 21.0.12+kerberos.ec.2 (30,5–34,8 MB por plataforma), y los 54 paquetes de agente suman 408,1 MB. La imagen Docker instala openjdk-17-jre-headless directamente. El diseño —descargar bajo demanda en lugar de incrustar— es razonable; la frase «No Java JRE» no lo es.

¿Cuántas bases de datos significa «más de 100»? La propia marquesina del sitio lista exactamente 100 nombres. Nueve son colas de mensajes o sistemas de descubrimiento de servicios, dos son variantes de versión, uno es un alias de producto y uno es el cajón de sastre JDBC, lo que deja 87 motores de datos distintos, 27 de ellos del mercado chino.

¿Me afecta CVE-2026-55642? Solo si expusiste dbx-web/Docker antes de la versión 0.5.51 sin contraseña configurada, y solo si ese puerto era alcanzable por clientes no confiables. La corrección está desde el 8 de julio de 2026 y el código actual falla cerrado. Comprueba si alguna vez ejecutaste una imagen antigua con 4224:4224 publicado a internet.

¿Por qué la insignia de descargas marca 2,8 M? Porque cuenta todas las descargas de artefactos y el 80,4% de ellas son el manifiesto latest.json del autoactualizador. Las descargas reales de artefactos en 306 versiones suman 545.888, y el artefacto real más descargado es el complemento JDBC, con 21.188.

¿Es realmente código abierto? Sí: Apache-2.0, con el catálogo de complementos, las claves de firma y la lista de revocación públicas, rechazo por defecto de complementos sin firma y versiones firmadas. Los matices están en el empaquetado (no está en Flathub; el paquete dbx-bin de AUR etiqueta mal la licencia como MIT), no en la licencia.

El veredicto

DBX es un producto real con un público real: 87 motores con una cobertura seria de bases de datos chinas, una arquitectura Tauri de verdad más ligera que la de sus rivales, un registro de agentes público, compilaciones firmadas, un registro de cambios honesto de 306 versiones y colaboradores que se cuentan por cientos. Si trabajas con los motores que cubre y aceptas su velocidad de actualización, hace algo que DBeaver no hace a ningún precio.

Lo que también tiene es una pila de marketing que ya no toca el artefacto. El tamaño del titular describe un instalador de una sola arquitectura; el recuento de motores incluye colas de mensajes, nombres de producto duplicados y un protocolo; la línea de «sin Java» sobrevive señalando los siete crates nativos mientras la aplicación descarga en silencio una JVM propia de 34,8 MB y 408 MB de agentes; y la insignia de descargas es cuatro quintos tráfico de máquinas. Y uno de sus trenes de versión —el que habla con tus bases de datos de producción por HTTP— arrastró un fallo de autenticación fail-open de CVSS 9,8 que se parcheó con competencia en julio y solo se convirtió en CVE en agosto.

Úsalo, fija la versión, define la contraseña, enlázalo a loopback, y lee las cifras en los artefactos, no en la fila de insignias.

Metodología

Todas las cifras se midieron el 30 de septiembre de 2026 (UTC). Los tamaños de artefacto y los contadores de descargas provienen de la API de versiones de GitHub sobre las 306 versiones de t8y2/dbx; el inventario de controladores y JRE, del artefacto agent-registry.json de la versión agents-v0.2.125; el tamaño instalado, de descargar DBX_0.6.28_amd64.deb (41.109.138 bytes) y descomprimirlo con dpkg-deb; el desglose de motores, del propio sitio en inglés del proyecto, deduplicado; las cifras de adopción, de las analíticas de cask de Homebrew entre el 30 de agosto y el 29 de septiembre de 2026, la API de Docker Hub, la API de descargas de npm y el RPC de AUR; los detalles de la vulnerabilidad, del registro CVE de MITRE y de OSV para CVE-2026-55642; y el comportamiento de autenticación, de leer crates/dbx-web/src/auth.rs y main.rs en main, además de deploy/Dockerfile y deploy/docker-compose.release.yml. Cuando una cifra es una inferencia y no una medición —por ejemplo, la estimación de base instalada—, el texto lo dice.