TigerBeetle: una base de datos pensada para transacciones financieras

Actualizado: 2026-05-03

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; Jepsen se ha aplicado sin hallazgos graves desde la primera versión estable.
• 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

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 u 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.

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.

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.

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.

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.

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. Algunas empresas cripto han empezado a usar TigerBeetle como contabilidad interna de intercambios.

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.

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.