Un filesystem tradicional te promete que el archivo va a estar ahí cuando lo necesites. No te promete que dos corridas del mismo programa, con el mismo input, vayan a tocar el disco exactamente en el mismo orden y con los mismos bytes en los mismos offsets. En la mayoría de los proyectos que pasaron por mis manos —backends que sirven HTTP, workers que procesan colas— esa garantía nunca hizo falta: con logs y un buen strace alcanzaba para debuggear. Pero para una base de datos financiera que necesita reproducir un estado byte a byte para auditoría o para testing con simulación, esa garantía deja de ser un lujo y se vuelve el problema entero.
Ahí entra TigerFS: la capa de almacenamiento que usa TigerBeetle, la base de datos de contabilidad financiera escrita en Zig. No es un filesystem de propósito general. Es una pieza de ingeniería construida para resolver una fricción muy específica — y ese recorte es justo lo que la hace interesante.
Qué problema resuelve TigerFS en una base embebida
El dolor concreto es este: cuando embebés el motor de almacenamiento dentro de tu proceso (sin pasar por un filesystem de propósito general como ext4 o XFS), perdés todas las garantías POSIX que asumís sin pensar — orden de escritura, atomicidad de fsync, comportamiento ante un crash a mitad de operación. Un filesystem tradicional te da esas garantías con matices que varían entre kernel, entre configuración de montaje, entre versión. Para debug normal, ese margen de variación no importa. Para un sistema que necesita simulación determinística — la misma ejecución, el mismo bug, reproducible mil veces — esa variación es ruido que tapa la señal.
TigerBeetle resuelve esto con un enfoque particular: en su suite de tests, reemplaza el filesystem real por una simulación completa de I/O que puede inyectar fallas de disco, reordenar escrituras y forzar corrupción de forma controlada y repetible. TigerFS es la pieza que hace que ese comportamiento simulado y el comportamiento real converjan en las mismas garantías, sin que el kernel meta variables no controladas en el medio.
Si ya leíste el post sobre Noroboto y su lectura técnica sin hype, la lógica es parecida: hay un problema de bajo nivel, específico, que no se resuelve con la herramienta genérica de siempre — hace falta una pieza construida a medida.
Qué dice la fuente oficial y qué no dice
El repositorio de TigerBeetle en GitHub es la fuente primaria de todo esto:
https://github.com/tigerbeetle/tigerbeetle
Lo que el repo documenta con claridad:
- TigerBeetle está escrito en Zig, no en Rust — corrijo esto explícitamente porque es un error común asumir Rust por el ecosistema de sistemas de bajo nivel donde suele aparecer este tipo de diseño.
- El proyecto declara determinismo como principio de diseño central: la misma secuencia de operaciones produce el mismo estado, siempre.
- Usa una técnica de testing por simulación (a veces llamada "deterministic simulation testing") donde el I/O de disco y de red se reemplaza por una versión simulada que permite reproducir exactamente el mismo escenario de falla.
- El diseño apunta a un caso de uso acotado: contabilidad financiera de doble entrada, con foco en durabilidad y consistencia estricta.
Lo que el repo no dice, y que conviene no inventar:
- No hay un benchmark público comparando TigerFS contra ext4 o XFS en términos de throughput o latencia.
- No hay documentación afirmando que TigerFS esté pensado para reemplazar un filesystem de uso general.
- No hay evidencia pública de que este diseño escale como solución genérica fuera del contexto de TigerBeetle.
Esa distinción entre lo que la fuente afirma y lo que uno podría inferir con entusiasmo es exactamente donde suele empezar el hype mal fundado.
Dónde se equivoca la gente con este tipo de diseño
La receta común cuando alguien lee sobre un sistema así es: "che, esto de determinismo total suena mejor que lo que tengo, lo aplico en mi proyecto". El costo oculto aparece rápido.
Un filesystem determinístico como el que describe el diseño de TigerFS asume un contexto muy particular: un motor de storage embebido, con control total sobre el layout de datos en disco, sin necesidad de interoperar con otras aplicaciones que también escriben en ese mismo filesystem. Eso es exactamente lo que necesita una base de datos financiera de propósito único. No es lo que necesita un backend típico que sirve archivos estáticos, loguea a disco y comparte el filesystem con quince procesos más — el tipo de setup con el que me crucé más de una vez en proyectos donde alguien quiso meter "la solución elegante" donde sobraba.
El contraejemplo más claro: si tu sistema necesita compatibilidad POSIX amplia — herramientas de terceros, backups estándar, montaje en distintos entornos — construir o adoptar algo con esta filosofía te resuelve un problema que no tenés y te crea uno que antes no tenías: mantenimiento de una pieza de infraestructura no estándar.
flowchart LR
A[Necesito storage embebido] --> B{¿Necesito reproducir estado exacto ante fallas?}
B -->|sí, es crítico| C[Evaluar diseño determinístico dedicado]
B -->|no, o es nice-to-have| D[Filesystem estándar + testing convencional]
C --> E[Costo: mantenimiento de pieza no estándar]
D --> F[Costo: menos control sobre orden exacto de I/O]
Matriz de decisión: cuándo mirar hacia este tipo de diseño
| Situación | ¿Vale la pena investigar un enfoque tipo TigerFS? | Qué mirar primero |
|---|---|---|
| Motor de base de datos embebido de propósito único (financiero, contable) | Sí, tiene sentido evaluarlo | Si el dominio exige reproducir fallas byte a byte |
| Backend típico con Postgres/MySQL detrás | No | El problema ya lo resuelve el motor de la base, no el filesystem |
| Sistema que necesita testing con simulación de fallas de disco | Vale la pena estudiar la técnica, no necesariamente el filesystem completo | Si podés simular a nivel de capa de aplicación en vez de reemplazar el filesystem |
| Proyecto con presión de interoperabilidad POSIX (backups, herramientas externas) | No | El costo de perder compatibilidad estándar suele superar el beneficio |
| Investigación académica o exploración de sistemas de bajo nivel | Sí, como lectura técnica | Leer el código fuente y los tests, no solo el marketing del concepto |
Esta matriz no es una fórmula cerrada. Es un punto de partida prudente para no comprar el diseño sin evaluar si el problema que resuelve es el problema que tenés.
Límites: qué no se puede concluir con esta evidencia
Ninguno de estos claims está respaldado por el repo público, así que no los voy a sostener como si lo estuvieran:
- No puedo afirmar que TigerFS sea más rápido o más lento que un filesystem tradicional — no hay benchmark público que lo mida.
- No puedo afirmar que este enfoque sea aplicable fuera del contexto específico de TigerBeetle sin evidencia de un caso de uso equivalente probado.
- No puedo afirmar que sea "el futuro del storage" — es una pieza de ingeniería acotada a un dominio, no una tendencia general de la industria.
Si alguien quiere validar el comportamiento determinístico en la práctica, el camino correcto es correr localmente la suite de tests del repo con Docker, revisar los logs de simulación de fallas, y comparar el comportamiento reproducido contra lo documentado — no inferirlo de un tuit con captura de gráfico.
Mi postura
Mi tesis es simple: TigerFS es un diseño elegante precisamente porque no intenta ser genérico. No es el próximo ext4, y decirlo no le resta valor — al contrario. Es una pieza construida para una fricción real y acotada: cuando necesitás que un bug se pueda reproducir exactamente igual mil veces, un filesystem de propósito general con sus variaciones de kernel y configuración se convierte en el enemigo, no en la solución.
Lo incómodo, para el que quiere aplicar esto en su proyecto: en la enorme mayoría de los casos que vi de cerca —backend con Postgres, colas, cron jobs, el combo de siempre— esa garantía de determinismo total sobra. No porque no sea valiosa en abstracto, sino porque tu problema real no es reproducir estado byte a byte, es que el deploy de un viernes rompió algo y necesitás un log decente, no un filesystem nuevo.
Si estás armando un sistema con requerimientos de consistencia fuerte parecidos a los de contabilidad financiera, vale la pena estudiar el enfoque en detalle antes de descartarlo por "sistemas de nicho". Si estás armando cualquier otra cosa, quedate con el filesystem estándar y resolvé el determinismo en la capa de testing de la aplicación — es más barato y lo vas a poder mantener sin depender de una pieza de infraestructura que pocos entienden.
La misma lógica de "elegir la herramienta correcta para el problema correcto, sin comprar el hype" aplica cuando decidís entre JWT sin estado y sesiones con estado, o cuando evaluás si necesitás Server Actions para resolver mutación sin resolver cache. El patrón se repite: la pregunta nunca es "¿es esto mejor en abstracto?", es "¿mi problema es el problema que esto resuelve?".
FAQ
¿TigerFS es un filesystem que se puede montar como ext4 o XFS?
No hay evidencia pública de que esté pensado para uso como filesystem de propósito general montable en cualquier sistema. Es una capa de almacenamiento diseñada para el contexto específico de TigerBeetle.
¿TigerBeetle está escrito en Rust?
No. TigerBeetle está escrito en Zig. Vale la pena aclararlo porque el ecosistema de sistemas de bajo nivel suele asociarse automáticamente con Rust.
¿Qué significa "determinismo" en este contexto?
Que la misma secuencia de operaciones, ejecutada con las mismas condiciones, produce exactamente el mismo estado final — sin variación introducida por el orden de I/O del sistema operativo o el scheduler.
¿Sirve este enfoque para bases de datos SQL tradicionales?
No hay evidencia pública de eso. El diseño responde a un caso de uso puntual (contabilidad financiera de doble entrada) y no está documentado como solución genérica para motores SQL.
¿Cómo se prueba el comportamiento determinístico sin acceso a producción?
Corriendo localmente la suite de tests del proyecto con Docker y revisando los escenarios de simulación de fallas que documenta el repo. Eso da una prueba reproducible sin necesitar datos productivos.
¿Vale la pena adoptar esta filosofía en un proyecto chico?
En general no. El costo de mantenimiento de una pieza de infraestructura no estándar suele superar el beneficio si el dominio no exige reproducibilidad exacta ante fallas de disco.
Fuente original: https://github.com/tigerbeetle/tigerbeetle
Este artículo fue publicado originalmente en juanchi.dev
