La pregunta que todos los founders hacen sobre cualquier base de datos
Tyler Cloutier, cofundador de Clockwork Labs, lo admite sin rodeos: la pregunta que más escucha sobre SpacetimeDB es «¿escala?». En un post técnico publicado el 4 de septiembre de 2026, responde con algo incómodo para la industria: la pregunta está mal formulada.
Su argumento central es que la «escalabilidad horizontal» no es una propiedad que un sistema tenga o deje de tener: es una propiedad del workload. Y para demostrarlo, desarma los tres ejes de cualquier sistema distribuido — compute, storage y networking — con ejemplos de bases de datos que muchos equipos de ingeniería eligen sin entender el costo real.
El dato clave que deja el post: lo que un solo núcleo puede resolver en ~3 microsegundos, un clúster distribuido mal coordinado puede terminar haciéndolo en 1 milisegundo por transacción. Bajo contención, un core bien afinado puede ser ~300 veces más rápido que un clúster que presume de distribuir la carga.
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidadPor qué «escala horizontal» no significa lo que crees
Cloutier parte de una definición operativa: un sistema escala horizontalmente cuando duplicar la cantidad de máquinas permite hacer, aproximadamente, el doble de trabajo. La trampa es que esa definición esconde tres dimensiones independientes que casi nunca se mueven juntas:
- Compute: cuántas transacciones puedes procesar por segundo.
- Storage: cuánta datos puedes almacenar.
- Networking: cuántas conexiones concurrentes y cuánto ancho de banda puedes sostener.
Para mostrarlo, contrasta tres bases de datos con interfaces PostgreSQL-compatibles pero arquitecturas opuestas:
- Postgres single-node: no escala automáticamente ninguna de las tres dimensiones; las réplicas de lectura ayudan con networking y compute, pero con caveats de consistencia.
- Neon: escala storage horizontalmente usando object storage con caché local de páginas, lo que le da almacenamiento prácticamente infinito, pero no escala compute ni networking de forma automática.
- CockroachDB / Spanner: escala las tres dimensiones en principio, repartiendo cada tabla en ranges replicados en varias máquinas.
A primera vista CockroachDB gana. La realidad es más amarga: paga un overhead de coordinación enorme incluso cuando la carga no se beneficia de distribuirse.
El problema de CockroachDB: coordinación bajo contención
Cloutier identifica dos problemas concretos del enfoque «escala todo horizontalmente»:
- Los datos de una transacción rara vez quedan co-localizados. Si repartes ownership al azar entre nodos, cada transacción termina haciendo saltos de red. Spanner lo mitigó parcialmente con table interleaving; CockroachDB lo soportó pero lo removió en la versión 21.2 porque los beneficios no justificaban la complejidad, según recuerda el propio blog.
- Ninguna transacción tiene acceso exclusivo a un rango, por lo que cada transacción paga costo de control de concurrencia distribuido y, ante conflicto, debe esperar, abortar o reintentar.
El número que resume el problema: una sección crítica de ~3 µs en un solo núcleo admite alrededor de 300.000 transacciones por segundo; al subir a 1 ms por la versión distribuida, cae a ~1.000 TPS. Aplicando la Ley de Amdahl a la escalabilidad horizontal: si solo el 1 % de las transacciones contienden por la misma fila, ningún clúster, por grande que sea, superará a un solo core optimizado.
El corolario es incómodo: comprar 10 cores para igualar lo que hace 1 core bien afinado es la norma, no la excepción, una vez que sumas sincronización cross-core, MVCC bookkeeping y round-trips de red.
Qué hace diferente a SpacetimeDB (y por qué nació single-threaded)
SpacetimeDB es la base de datos relacional que también es servidor: subes la lógica de tu aplicación directamente a la base y los clientes se conectan sin un backend intermedio, como explica el README oficial en GitHub. Soporta módulos en Rust, C#, TypeScript y C++, garantiza ACID y mantiene todo el estado en memoria con un commit log en disco.
Su arquitectura sorprende: la ejecución es single-threaded por diseño. Cloutier cuenta que las primeras versiones del motor eran paralelas con transacciones MVCC; cuando midieron, single-thread ganó. «Probablemente nos costó más de USD 1M solo para entender que debíamos usar un gran lock», escribe.
La razón es la misma que ya describimos: bajo contención, la coordinación mata el throughput. El motor se apoya en el modelo actor — descrito en el blog como «un modelo general de computación paralela motivado por la perspectiva de máquinas altamente paralelas con docenas, cientos o miles de monoprocesadores independientes» — donde cada base de datos es un actor single-threaded con su propio estado y log de transacciones.
El resultado en benchmarks internos: ~300.000 TPS para las transacciones de prueba, tanto en bases replicadas como no replicadas, siempre que haya ancho de banda y memoria suficientes para el pipeline.
El roadmap en 6 pasos hacia la escalabilidad horizontal
Clockwork Labs no niega que necesite escalar horizontalmente. Lo que propone es hacerlo de forma explícita y ergonómica, con un plan publicado:
| Paso | Feature | Estado |
|---|---|---|
| 1 | Réplicas con rendimiento clase mundial | Disponible hoy |
| 2 | Sharding con experiencia usable (IDC asíncrono) | 31 de octubre de 2026 |
| 3 | Storage horizontal por base de datos (tiered storage) | 31 de octubre de 2026 |
| 4 | Networking horizontal (réplicas de lectura) | Planeado |
| 5 | Transacciones inter-base de datos (IDC síncrono) | Planeado |
| 6 | Particiones intra-base | Planeado |
El paquete que ya tiene fecha, 31 de octubre de 2026 bajo el nombre Spacetime Continuum, incluye:
- IDC asíncrono: una base llama funciones de otra de forma tipada, sin bloquear.
- Tiered storage: tablas en disco y object storage, tratando al storage como un caché multinivel (memoria = L4, disco = L5, object storage = L6). El blog lo llama «diagonal scaling», un término que el equipo de TigerBeetle también usa, basado en anti-caching de H-Store y reconnaissance queries de Calvin.
Como los reducers son deterministas — no hacen I/O, no leen reloj, no generan aleatoriedad — abortarlos es prácticamente gratis y re-ejecutarlos contra el mismo estado toca exactamente las mismas filas. Esa es la propiedad que hace viable tiered storage sobre single-thread.
Lo que esto significa para tu startup
Si estás eligiendo una base de datos OLTP para un producto con contención real (pagos, inventarios, ranking, sesiones de juego, cualquier cosa con hot keys), este post es una señal de alerta contra la cultura del «solo agrégale más servidores».
- Acciones concretas que puedes tomar hoy:
- Mide contención antes de elegir arquitectura. Antes de decidir entre Postgres, CockroachDB, Spanner, Neon o SpacetimeDB, instrumenta cuántas transacciones contienden por la misma fila o shard. Si la contención es alta, escala vertical primero.
- Diseña sharding explícito desde el día uno. El enfoque de SpacetimeDB — hacer la frontera del shard explícita y ergonómica — es replicable en cualquier stack: agrupa los datos por entidad (usuario, sesión, región) para que la transacción común no cruce límites.
- Evalúa tiered storage si tu dataset crece. El patrón de tratar disco y object storage como caché (no como almacenamiento primario) permite combinar capacidad barata con latencia predecible; vale la pena explorarlo aunque uses Postgres o DynamoDB.
Un dato sobre BitCraft que ayuda a dimensionar todo
BitCraft Online, el MMORPG sandbox de Clockwork Labs, corre toda su backend como un único módulo de SpacetimeDB — chat, items, terreno, posiciones de jugadores — sincronizando a miles de jugadores en tiempo real, según el README oficial. El juego entró en early access en junio de 2025 en Steam a USD 30 y, según DualShockers, superó las 100.000 wishlists antes del lanzamiento. La empresa también anunció que abrirá el código del juego tras el EA, una decisión que Cloutier vincula directamente a la estrategia de adopción de SpacetimeDB: dar a los estudios indie un ejemplo completo de cómo construir un MMO encima de la base de datos, entrevistado por mmorpg.com.
Ese caso de uso — un mundo persistente editable por miles de jugadores simultáneos — es exactamente el workload para el que SpacetimeDB está optimizado, y el escenario contra el que Clockwork Labs está ajustando cada paso del roadmap hasta el 31 de octubre de 2026.
Fuentes
- Ok, but Does It Scale? — SpacetimeDB Blog (fuente original)
- SpacetimeDB — clockworklabs/SpacetimeDB (GitHub)
- Interview: Talking BitCraft’s Early Access Launch, Open Source, And More — mmorpg.com
- Upcoming MMORPG BitCraft Makes Bold Move With Latest Announcement — DualShockers
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad
