TigerBeetle: una base de datos pensada para transacciones financieras
Actualizado: 2026-07-07
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.
Puntos clave
-
TigerBeetle solo hace una cosa: contabilidad por partida doble. Dos tablas fijas, cuentas y transferencias, sin posibilidad de crear tablas nuevas, añadir columnas o hacer búsqueda textual.
-
Está escrito en Zig deliberadamente: control bajo nivel de memoria, cero dependencias dinámicas, comportamiento predecible bajo presión.
-
Usa Viewstamped Replication en clusters de cinco nodos tolerando fallos de dos, con réplica síncrona del libro mayor.
-
Usa verificación formal y simulación determinista; una auditoría independiente de Jepsen en 2025 encontró fallos menores de disponibilidad, pero ningún fallo grave en la garantía central de serializabilidad estricta del libro mayor.
-
La arquitectura típica es TigerBeetle junto a una base de datos tradicional: Postgres guarda usuarios, productos y metadatos; TigerBeetle guarda el libro mayor.
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
TigerBeetle nació como proyecto interno de Coil, una startup de pagos por internet, donde su creador, Joran Dirk Greef, construía infraestructura de cobros y había consultado antes sobre el switch de pagos de un banco central. Desde esa posición vio de cerca 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 seguía usando Postgres u Oracle configurados con mucha gimnasia. Según Amplify Partners[1], registrar un solo movimiento de débito y crédito en un sistema SQL genérico exige entre 10 y 20 consultas (leer saldos, bloquear filas, esperar la lógica de aplicación, escribir de vuelta), mientras países como India o Brasil ya procesan miles de millones de transacciones al mes.
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 del código, público en GitHub[2] desde 2020, se independizó de Coil como empresa propia y cerró una ronda semilla de 6,4 millones de dólares a comienzos de 2023 y una serie A de 24 millones liderada por Spark Capital en 2024, según TechCrunch[3]. El proyecto sigue en versionado 0.x, sin haber declarado todavía un 1.0, con lanzamientos frecuentes y una comunidad de uso creciente entre empresas de pagos y fintech.
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 hasta el punto de invertir en el propio lenguaje: en octubre de 2025, junto con Synadia, donó 512.000 dólares a la Zig Software Foundation[4].
El protocolo de consenso es Viewstamped Replication, variante poco conocida fuera de círculos académicos pero elegante y probada, con quórums flexibles diseñados por Heidi Howard. La aritmética clásica de tolerancia a fallos exige 2f+1 réplicas para tolerar f caídas simultáneas: dos fallos requieren un mínimo de cinco nodos. La documentación oficial[5] va más allá para producción y recomienda seis réplicas repartidas entre tres proveedores cloud distintos, dos por proveedor, para sobrevivir incluso a la caída completa de uno de ellos. Antes de responder al cliente, cada transferencia debe estar registrada en una mayoría de réplicas del clúster. Esta misma disciplina de replicación es la que compara con el modelo de replicación lógica de Postgres 16, pensado para un problema distinto: sincronizar bases relacionales completas, no un libro mayor de contabilidad.
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 datos quedan, según la propia documentación, con suma de verificación y encadenados por hash. 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.
La verificación formal es parte central del proyecto: TigerBeetle usa simulación determinista para probar el sistema bajo secuencias de fallos generadas por su propio fuzzer, el VOPR. En 2025 encargó además una auditoría independiente a Jepsen[6], que probó las versiones 0.16.11 a 0.16.30. El informe encontró un par de fallos menores, como resultados incompletos en consultas con varios predicados, y varios choques de cliente y servidor en casos límite de actualización, pero concluyó que la base de datos cumplía su promesa de serializabilidad estricta y que la mayoría de los hallazgos eran caídas o pérdida de rendimiento, no errores de seguridad en el libro mayor; TigerBeetle corrigió casi todos en versiones posteriores, según su propio resumen del proceso[7]. Esto importa en contabilidad: un bug que pierde un centavo en un millón de transferencias es inaceptable, y ese es exactamente el tipo de fallo que ni el fuzzer interno ni Jepsen lograron provocar.
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 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. Un ejemplo verificable es Rafiki[8], la implementación de referencia de Interledger Foundation para Open Payments, que usa TigerBeetle como motor de contabilidad y deja Postgres para la autenticación y los recursos de la aplicación.
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. Esta misma lógica de usar la herramienta correcta para cada carga aplica a lo que analizamos en Citus para escalar Postgres: cada problema requiere la herramienta diseñada para él.
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. 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.
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. El propio informe de Jepsen señaló un diseño discutible: el cliente reintenta indefinidamente en lugar de devolver un error explícito a la aplicación, algo que complica el manejo de fallos en el código que lo consume.
Cómo pensar la decisión
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.
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.
Conclusión
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.
Versión en inglés: TigerBeetle: a database built for financial transactions.
