BerryDB: cliente de bases de datos nativo para macOS
En pocas palabras: El equipo de BerryDB Desktop lo escribió en Swift y AppKit, sin Electron, para evitar el consumo de memoria de Chromium: según el post del 7 de octubre de 2026, usa unos 45 MB de RAM en reposo frente a 700 MB–1,2 GB de los clientes Electron.
Si buscaste «apple why built», la respuesta es BerryDB Desktop. El 7 de octubre de 2026 su equipo explicó en un post en dev.to por qué escribió un cliente de bases de datos open source para macOS en Swift y AppKit, sin Electron. Declara unos 45 MB de RAM en reposo y 9 motores soportados.
BerryDB Desktop es un cliente de bases de datos open source (licencia Apache 2.0) para macOS, escrito en Swift con AppKit, que conecta PostgreSQL, MySQL/MariaDB, SQLite, SQL Server, Redis/Valkey, MongoDB, DynamoDB, Elasticsearch y Qdrant desde una sola ventana con pestañas. Lo desarrolla el proyecto berry-apps, no Apple. Se instala con Homebrew o con un .dmg e incluye un asistente de IA para SQL.
En este artículo:
- En 30 segundos
- ¿Qué bases de datos soporta BerryDB Desktop?
- ¿Por qué construyeron BerryDB para Apple y no con Electron?
- ¿Cuánta RAM y qué velocidad de arranque tiene BerryDB frente a clientes Electron?
- ¿Cómo renderiza millones de filas sin trabarse?
- ¿La IA de BerryDB corre local y dónde guarda las credenciales?
- ¿Qué requisitos tiene BerryDB y qué límites hay que tener en cuenta?
- Qué está confirmado y qué no
- Errores comunes
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- BerryDB es gratis, Apache 2.0, y según los autores no tiene límite de pestañas ni de workspaces.
- Los autores declaran ~45 MB de RAM en reposo y arranque en frío menor a 200 ms; el README del repo habla de unos 0,85 s hasta la primera ventana.
- Pide macOS 15 (Sequoia) o superior y, según el README, solo Apple Silicon (M1 a M4).
- Todas las cifras son de los propios autores y no hay prueba independiente. Probalo contra una base de desarrollo antes de tocar producción.
¿Qué bases de datos soporta BerryDB Desktop?
BerryDB soporta nueve motores en un workspace con pestañas, según la matriz de compatibilidad del README: PostgreSQL, MySQL/MariaDB, SQLite, SQL Server, Redis/Valkey, MongoDB, DynamoDB, Elasticsearch y Qdrant. Los drivers son Swift puro en la mayoría de los casos, y SQL Server usa FreeTDS.
- Relacionales: PostgreSQL 12 a 16+ (PostgresNIO), MySQL 5.7 y 8.x (MySQLNIO), SQLite 3.x (libsqlite3) y SQL Server 2017+ (FreeTDS).
- Clave-valor: Redis y Valkey 6.x a 8.x, con visores para strings, hashes, listas, sets y sorted sets.
- Documentos y nube: MongoDB 5.x a 7.x con editor JSON, y DynamoDB con PartiQL y autenticación SigV4.
- Búsqueda y vectores: Elasticsearch 7.x y 8.x, y Qdrant. En ambos la grilla es de lectura y búsqueda, sin edición inline.
Ejemplo hipotético: tenés un Postgres de staging, un Redis para colas y un Qdrant para embeddings. Hoy abrís tres apps; con esto, tres pestañas.
Una aclaración sobre la fuente: el post de dev.to es difusión de los propios autores, no cobertura independiente. Lo que sí podés contrastar es el README del repositorio, que confirma la lista de motores.
¿Por qué construyeron BerryDB para Apple y no con Electron?
Los autores sostienen que un cliente que vive todo el día en el dock no debería cargar un Chromium y un runtime de Node propios. En el post lo plantean como una tercera opción entre los clientes pesados y los nativos con límites: «un cliente de bases de datos para macOS rápido, 100% open source y nativo que trata con respeto los recursos de tu sistema» (traducción nuestra). Te puede servir nuestra cobertura de soporte de Linux para el chip T1.
Citan dos costos de Electron: presión del recolector de basura al renderizar 100 columnas por 50.000 filas en HTML/CSS, y una experiencia que no se siente nativa en teclado, scroll con inercia y barra de menú. Es un argumento razonable y conocido. Lo que no demuestra es que tu caso particular sufra esos costos.
¿Cuánta RAM y qué velocidad de arranque tiene BerryDB frente a clientes Electron?
Según la tabla del post de los autores, BerryDB usa unos 45 MB de RAM en reposo y arranca en frío en menos de 200 ms. Declaran 700 MB a 1,2 GB y 4 a 8 segundos para los clientes Electron. El post no publica metodología.
| Métrica | BerryDB Desktop | Clientes Electron | Nativo propietario |
|---|---|---|---|
| RAM en reposo | ~45 MB | 700 MB a 1,2 GB | ~60 MB |
| Arranque en frío | menos de 200 ms | 4 a 8 s | ~300 ms |
| Scroll | 120 FPS (ProMotion) | 30 a 60 FPS | 120 FPS |
| Límites en versión gratis | Ninguno | Mixto | 2 pestañas / 2 workspaces |
| Licencia | Apache 2.0 | Open source / freemium | Código cerrado |

Ahora bien, el README del repo no coincide del todo. Habla de arranque «bajo 1 s» y detalla que una ventana aparece unos 0,85 s después de un arranque en frío, medido en un Apple M1 de 16 GB con macOS 26.6.2 y build de release. Aclara además que el tiempo de spawn del proceso y el de la primera ventana son números distintos.
Mi lectura (es inferencia, no dato confirmado): la cifra de menos de 200 ms probablemente mide otra cosa que los 0,85 s. Mientras no se aclare, tomalo con pinzas y no cites los dos números como si fueran el mismo.
¿Cómo renderiza millones de filas sin trabarse?
BerryDB combina streaming binario desde el socket del motor hacia structs nativos de Swift con una grilla NSTableView que instancia solo las filas visibles. Según los autores, así evitan parsear JSON en WebViews y el scroll se mantiene a 120 FPS con 2.000.000 de filas y memoria casi plana. Para más detalles técnicos, mirá el caso de Omarchy en las Mac.
- Streaming binario: los resultados no pasan por JSON ni por el DOM, que es donde Electron sufre con tablas grandes.
- Virtualización de filas: el README declara unos 5,5 MB de memoria pico al transmitir 1.000.000 de filas, lo mismo que con 200.000.
Es un dato interesante porque la memoria no escala con el tamaño del resultado. Falta la contraparte: ninguna fuente muestra una medición independiente ni compara contra otro cliente en la misma máquina. El README sí incluye scripts/measure-performance.sh para reproducir las cifras en tu equipo.
¿La IA de BerryDB corre local y dónde guarda las credenciales?
Según el post, el autocompletado y la explicación de consultas corren 100% en el dispositivo, sin telemetría ni transferencia de datos a la nube, y las claves SSH y credenciales quedan en el Llavero de Apple y el Secure Enclave. Son afirmaciones de los autores, no verificadas por terceros.
Hay un matiz. El README describe un copilot que genera SQL a partir de lenguaje natural con inyección automática del esquema y un panel de chat con tu base, pero no aclara si esa generación corre también on-device. El post menciona local solo para autocompletado y explicación.
Instalás la app, la abrís, conectás la base de staging, corrés un par de consultas, te encanta cómo scrollea, la apuntás a producción el viernes a la tarde y recién ahí te preguntás qué viaja por la red cuando le pedís algo al copilot. En diferencias entre OrbStack y Multipass en Mac profundizamos sobre esto.
Para no llegar a esa pregunta tarde, esta es una propuesta editorial (no la atribuimos a la fuente ni la probamos nosotros):
- Empezá con un usuario de solo lectura sobre una base de desarrollo.
- Mirá el tráfico saliente con la herramienta de monitoreo que uses mientras activás el copilot.
- Revisá el código en GitHub, que es lo que habilita la licencia Apache 2.0, antes de conectar producción.
¿Qué requisitos tiene BerryDB y qué límites hay que tener en cuenta?
BerryDB pide macOS 15.0 (Sequoia) o superior y Apple Silicon (M1 a M4), según el README. Lo instalás con brew install --cask berry-apps/tap/berrydb o bajando el .dmg desde GitHub Releases. Para compilarlo necesitás Xcode 16+ con Swift 6 y brew install freetds.
- Proyecto joven: las fuentes consultadas no permiten medir su adopción ni su trayectoria.
- Solo macOS: no hay versión para Windows ni Linux.
- Issue #8: etiquetado como bug y fechado el 15 de septiembre de 2026, reporta que libsybdb (FreeTDS) dentro del .app está compilada para macOS 15 mientras la app declaraba soporte para macOS 14. La página lo muestra como cerrado, sin el detalle de la corrección.
Que el issue figure cerrado no confirma qué se cambió. Lo razonable es asumir macOS 15 como piso, que es lo que dice hoy el README.
Qué está confirmado y qué no
- Confirmado en el repo: licencia Apache 2.0, lista de nueve motores, requisitos de macOS 15 y Apple Silicon, comando de Homebrew y script de medición.
- Declarado sin verificación externa: 45 MB de RAM, arranque menor a 200 ms, 120 FPS con 2.000.000 de filas, ejecución local de la IA y cero telemetría.
- Pendiente: metodología de la tabla comparativa, aclaración de la diferencia entre 200 ms y 0,85 s, y detalle de la corrección del issue #8.
Errores comunes
- Citar la tabla como benchmark independiente. Es del propio proyecto y no explica cómo midió. Corrección: citá “según los autores” o corré el script en tu Mac.
- Conectar producción el primer día. Con un proyecto joven, arrancá con una base de desarrollo y un usuario de solo lectura.
- Instalarlo en una Mac Intel o con macOS 14. El README pide Apple Silicon y macOS 15+. Revisalo en “Acerca de esta Mac” antes de probar.
- Dar por hecho que toda la IA es local. El post lo afirma para autocompletado y explicación; el resto del copilot no queda claro.
Preguntas Frecuentes
¿Qué es BerryDB Desktop y para qué sirve?
BerryDB Desktop es un cliente de bases de datos open source para macOS, escrito en Swift y AppKit. Sirve para consultar, navegar y editar datos de PostgreSQL, MySQL, SQLite, SQL Server, Redis, MongoDB, DynamoDB, Elasticsearch y Qdrant desde una sola app. Esto se conecta con lo que analizamos en cómo se compara Apple con Google.
¿BerryDB es gratis y open source?
Sí, es gratis y open source bajo licencia Apache 2.0, libre para uso personal y comercial según el README. Los autores dicen que no hay restricciones en la versión gratuita y aceptan donaciones en Ko-fi.
¿Cómo se instala BerryDB en macOS con Homebrew?
Ejecutá brew install --cask berry-apps/tap/berrydb en la terminal. También podés agregar el tap con brew tap berry-apps/tap y después correr brew install --cask berrydb.
¿Funciona BerryDB en Macs con procesador Intel?
No, según el README solo funciona en Apple Silicon (M1, M2, M3 y M4) con macOS 15.0 o superior. Las fuentes consultadas no mencionan una versión para Intel.
¿Qué bases de datos soporta BerryDB en Mac?
Soporta PostgreSQL, MySQL/MariaDB, SQLite, SQL Server, Redis/Valkey, MongoDB, DynamoDB, Elasticsearch y Qdrant. En Elasticsearch y Qdrant la grilla es de lectura y búsqueda, sin edición inline.
Conclusión
BerryDB es una propuesta interesante para quien usa un Mac con Apple Silicon y harta de pagar RAM por una grilla de datos. La arquitectura que describen (streaming binario y NSTableView virtualizado) es coherente, y que el código sea abierto permite revisarlo.
Lo que no podés concluir hoy es que sea más rápido o liviano que lo que ya usás, porque las cifras son propias y hay una diferencia sin explicar entre 200 ms y 0,85 s. Mi recomendación: instalalo, corré el script de medición, probalo con una base de desarrollo y decidí con tus propios números.






