TigerBeetle es uno de esos proyectos que cuando los encuentras por primera vez te hacen dudar si son una broma técnica o una obra seria. Una base de datos especializada solo en dos tipos de operaciones, escrita en Zig, con un esquema rígido de dos tablas fijas, que pretende procesar millones de transacciones financieras por segundo en un cluster de cinco máquinas. La primera reacción es incredulidad. La segunda, tras leer los documentos de diseño y los artículos de los creadores, es respeto profundo por la seriedad técnica. TigerBeetle no es para todos los problemas, pero para el suyo, es un ejemplo notable de diseño enfocado.
Qué es y qué no es
TigerBeetle es una base de datos de propósito muy específico: contabilidad por partida doble, la técnica que llevan usando contables desde el siglo XV para registrar cada movimiento económico como una entrada con dos patas que siempre cuadran. Cada transferencia produce un débito en una cuenta y un crédito en otra, y la suma total siempre es cero. Esa propiedad matemática es la base de todo sistema financiero serio, y TigerBeetle la modela directamente en su esquema.
El esquema es de una simplicidad voluntaria: dos tablas fijas, una de cuentas y otra de transferencias. Las cuentas tienen un identificador, un saldo deudor, un saldo acreedor, un código de moneda y un libro contable. Las transferencias tienen un identificador, una cuenta débito, una cuenta crédito, un importe y un conjunto de banderas. Eso es todo. No puedes crear tablas nuevas, no puedes añadir columnas, no hay JSON ni búsqueda textual. La base de datos hace contabilidad o no hace nada.
Esta rigidez es el punto fuerte. Un sistema que solo tiene que hacer una cosa puede optimizarse brutalmente para hacerla bien. TigerBeetle procesa transferencias en lotes, las valida en memoria, mantiene un libro mayor inmutable, replica el estado mediante un protocolo de consenso, y todo eso lo hace a velocidades que los sistemas de propósito general simplemente no alcanzan.
Por qué fue creado
Los creadores de TigerBeetle vienen del sector financiero: exbanqueros, ingenieros que operaron sistemas de pagos a gran escala en Australia. Observaron que la contabilidad transaccional es una carga peculiar: muy alta tasa de escritura, operaciones conceptualmente sencillas pero con reglas estrictas, cero tolerancia a pérdida de datos, reglas de latencia exigentes. Y sin embargo la industria usaba Postgres o Oracle configurados con mucha gimnasia y cuellos de botella constantes.
La tesis fue que si construyes una base de datos desde cero para esa carga concreta, con todos los atajos que el propósito específico permite, los resultados pueden ser órdenes de magnitud mejores que los de una base general bien ajustada. TigerBeetle no compite con Postgres en feature parity; compite con Postgres cuando la carga es exactamente la que TigerBeetle modela, y ahí TigerBeetle gana por mucho.
El desarrollo empezó en 2020 y el proyecto fue público desde casi el inicio. La primera versión estable llegó en 2024, y durante 2025 ha habido despliegues públicos en empresas de pagos y fintech, incluidas integraciones con sistemas como Mambu para banca digital. El equipo mantiene una cadencia de publicaciones técnicas alta y el código es muy revisado.
Diseño: lo que lo hace distinto
El lenguaje es Zig, elección deliberada. Los creadores querían control bajo nivel de memoria, cero dependencias dinámicas, comportamiento predecible bajo presión, y ausencia de runtime complejo. Zig ofrece eso con una ergonomía que C no alcanza y sin la complejidad creciente de Rust. TigerBeetle ha crecido con Zig y sus creadores son contribuyentes habituales al lenguaje, lo que significa que cuando Zig tiene un bug o una carencia, ellos están en posición de solucionarlo.
El protocolo de consenso es Viewstamped Replication, variante poco conocida fuera de círculos académicos pero elegante y probada. TigerBeetle corre en clusters de cinco nodos tolerando fallos de dos, con réplica síncrona del libro mayor. El diseño del protocolo es deliberadamente conservador: antes de responder al cliente, la transferencia debe estar en el libro de al menos tres nodos. Esto cambia la mentalidad respecto a sistemas que priorizan latencia y sacrifican durabilidad en fallos raros.
El formato de almacenamiento es propio. Un libro mayor inmutable en disco, donde cada transferencia se añade al final y nunca se modifica. Los saldos de cuenta se recalculan en memoria a partir del libro cuando hace falta. Esto le da propiedades fuertes: auditoría perfecta, replicación simple, tolerancia natural a corrupciones porque nada se sobrescribe. El coste es que el libro crece indefinidamente, aunque comprimido y archivado.
La verificación formal es parte central del proyecto. TigerBeetle usa técnicas de simulación determinista para probar el sistema bajo todas las secuencias posibles de fallos, y herramientas como Jepsen se han aplicado sin hallazgos graves desde la primera versión estable. Esto es importante en contabilidad: un bug que pierde un centavo en un millón de transferencias es inaceptable, y TigerBeetle se diseñó con esa conciencia desde el inicio.
Dónde encaja
El caso de uso claro es el sistema de pagos a escala. Cualquier plataforma que procese transferencias entre cuentas, tarjetas de pago, liquidaciones entre entidades, puntos de fidelidad o monederos virtuales es candidata natural. La regla es que si la carga principal de la aplicación es contar dinero que va de aquí a allá, y la tasa supera unas decenas de miles de operaciones por segundo, TigerBeetle merece evaluación.
También encaja en mundos adyacentes: plataformas de juego con economías internas, marketplaces con comisiones complejas, sistemas de facturación a escala de nube, cualquier escenario donde la integridad del libro mayor es crítica y el volumen es alto. Algunas empresas cripto han empezado a usar TigerBeetle como contabilidad interna de intercambios, separando la lógica de blockchain de la contabilidad clásica que todo intercambio necesita.
La arquitectura típica es TigerBeetle junto a una base de datos tradicional. Postgres guarda usuarios, productos, metadatos y búsqueda; TigerBeetle guarda el libro mayor. Las aplicaciones consultan ambas según la necesidad: datos descriptivos en Postgres, saldos y transferencias en TigerBeetle. Esta separación es explícita y recomendada por los creadores, que no pretenden que TigerBeetle sustituya a una base relacional.
Limitaciones honestas
TigerBeetle no hace consultas analíticas. Si quieres saber cuánto gastó un usuario en enero por categoría, esa no es la pregunta que TigerBeetle responde. El libro mayor está optimizado para escribir y para recomputar saldos, no para analizar patrones. Para análisis, exportas a un data warehouse como siempre.
Tampoco hace texto, geografía, JSON o cualquier tipo de datos fuera del modelo financiero estricto. La abstracción es cerrada a propósito. Si tu aplicación tiene requisitos que no caben en cuentas y transferencias, TigerBeetle es una pieza entre varias, no la solución completa.
La operación es relativamente nueva. Las herramientas de observabilidad y diagnóstico están madurando. La comunidad es pequeña comparada con Postgres. Un problema extraño un domingo por la noche tiene menos respaldo que el mismo problema en un sistema clásico. Esto no impide usar TigerBeetle en producción pero obliga a tener un plan y habilidad interna para resolverlo.
Comparación con alternativas
La alternativa más frecuente es Postgres con un diseño cuidadoso del libro mayor: tablas normalizadas, restricciones de integridad, transacciones serializables. Es lo que hace la mayoría del sector hoy. Funciona, pero tiene techo claro en volumen y latencia, y mantiene la carga operativa de recordar siempre qué columna actualizar para que los saldos cuadren.
CockroachDB o YugaByte dan escalabilidad horizontal pero no se especializan en contabilidad. La eficacia es menor por operación, aunque ganan en uniformidad con el resto del stack.
Soluciones propietarias como las de los grandes bancos son cajas negras costosísimas. Para una fintech emergente no son viables.
TigerBeetle ocupa un espacio nuevo entre estas opciones: software libre, especializado, con garantías formales, y con coste operativo razonable si sabes dónde aplicarlo.
Cómo pensar la decisión
Mi lectura es que TigerBeetle merece estudio serio si estás construyendo algo donde la contabilidad es el corazón del negocio y el volumen crece rápido. El coste de introducirlo es real: otra base de datos que operar, otro modelo mental que aprender, separación explícita entre datos financieros y el resto. Pero el beneficio es tangible: rendimiento que no obtienes de ninguna otra manera, garantías formales que te quitan el miedo a descuadres sutiles, y un equipo detrás del proyecto con seriedad técnica poco frecuente.
No hay que apresurarse. Si tu volumen es de decenas o cientos de transferencias por segundo, Postgres bien configurado es probablemente la respuesta correcta hoy y lo seguirá siendo mucho tiempo. Si empiezas a ver cientos de miles por segundo o millones, o si la naturaleza de tu negocio tiene riesgo regulatorio sobre la integridad del libro mayor, TigerBeetle ofrece un punto en el mapa que ninguna otra opción ocupa bien.
Es el tipo de herramienta que, cuando la necesitas, la necesitas mucho; y cuando no la necesitas, es una complejidad que no compensa. Esa claridad sobre su nicho es parte de por qué el proyecto inspira confianza: sus creadores saben exactamente qué construyen y para quién, y no intentan convertirlo en otra cosa.
