¿Escala horizontalmente? SpacetimeDB responde: no toda la computación se puede escalar así
Ok, but Does It Scale?
SpacetimeDB aborda la pregunta más frecuente sobre su arquitectura: cómo escala. Explica que existen tres dimensiones de escala: cómputo, almacenamiento y red. Mientras que el almacenamiento horizontal es sencillo (y llegará en octubre de 2026), el cómputo y la red no siempre se pueden escalar horizontalmente. Compara Postgres, Neon y CockroachDB, señalando que las bases de datos OLTP que escalan horizontalmente suelen pagar una enorme sobrecarga por transacción y rinden mal ante transacciones en contención. SpacetimeDB ofrece alto rendimiento bajo contención y herramientas para escalar cargas OLTP paralelizables.
La verdad incómoda es que, en lugar de hacer más con más computadoras, la escalabilidad horizontal a menudo puede significar hacer menos con más computadoras: conceptualmente, lo que una computadora puede hacer en 1 milisegundo, 10 computadoras pueden hacerlo en 100 milisegundos.
- timssopomo
Spacetime suena como una tecnología realmente interesante, pero no estoy seguro de que la comparación con CRDB sea buena.
Solía trabajar en Cockroach Labs. El problema que resuelve es fundamentalmente diferente. CRDB como solución tiene sentido cuando necesitas _garantizar_ que las transacciones sean serializables y duraderas, y que tu aplicación pueda sobrevivir a fallos de nodos o regiones manteniendo la consistencia. En una implementación ingenua, es significativamente más lento que operar en un solo núcleo, pero ese es el precio que pagas por la capacidad de sobrevivir a la pérdida de nodos sin pérdida de datos.
No veo nada que indique cómo spacetime resuelve el problema central que CRDB resuelve, que es garantizar que los fallos de un solo nodo puedan tolerarse con cero pérdida de datos o pérdida de disponibilidad. Suena como que las transacciones por defecto deben escribirse en disco antes de completarse, lo que las hace duraderas en un solo nodo, pero no puedes asegurar que sean consistentes entre nodos sin aceptar la sobrecarga de red y perder rendimiento de transacciones (en escrituras, de todos modos).
Además, por si sirve de algo, en los varios años que trabajé cubriendo básicamente todos los incidentes, no recuerdo haber visto un clúster limitado por red. Como todo lo demás, hay compensaciones. Cedes rendimiento, obtienes consistencia y disponibilidad, y no necesitas ingeniar cómo evitar la pérdida de datos o la disponibilidad con fallos de nodos. A menos que me esté equivocando, spacetime está resolviendo un problema totalmente diferente.
- chermi
Fuera de tema pero... tenía un amigo cuya principal conclusión (en broma) del mini-MBA de Harvard mientras estaba en un programa de SEAS era que todo lo que tenías que hacer para parecer inteligente alrededor de gente de negocios de VC/tech era hacer esta pregunta.
Luego realmente fundamos una startup y nos dimos cuenta de que esta no era una pregunta tonta. Pero quizás eso es circular cuando el camino predeterminado es la financiación de VC, hmm.
- philippta
Hice una comparativa de Postgres en configuración de un solo nodo y de varios nodos contra CockroachDB hace un tiempo y mis hallazgos coinciden con lo que este post está diciendo.
https://github.com/philippta/postgresql-cockroachdb-benchmar...
- echohack5
Como alguien que ha estado usando mucho spacetime para proyectos secundarios (como https://heat.echohack.app), estoy continuamente impresionado por la velocidad a la que opera.
Creo que hay muchas cosas interesantes sucediendo en el espacio de las bases de datos. Vitess/Neki, almacenes de vectores, spacetime son todas cosas realmente buenas que están sucediendo. Creo que es una pena que los desarrolladores de bases de datos parezcan tener una línea de tiempo llena de drama. Es... todo muy emocionante, en conjunto.
De todos modos, algunas cosas que necesitan mejorar (algunas de las cuales se abordan en esta publicación de blog):
1. Copias de seguridad (recuperación rápida) y recuperación ante desastres (recuperación lenta y duradera)
Esta es una grande, pero a veces la velocidad no es el único objetivo que debes cumplir. Necesitas tener la certeza de que, si todo se cae, (eventualmente) puedas traer las cosas de vuelta en línea. Realmente no tengo una manera de hacer eso hoy.
2. Las réplicas de lectura serían muy útiles para cargas de trabajo analíticas
3. Escrituras duraderas a S3 serían útiles para cargas de trabajo ráfaga intermitentes (como sistemas de CI)
Creo que la gente de Spacetime tiene trabajo por delante, no necesariamente por la tecnología (eso también es difícil) sino porque los modelos de IA aparentemente han decidido que Neon y Postgres son todo lo que existe.
Creo que spacetime tiene un futuro brillante por delante, y les deseo todo lo mejor al equipo mientras trabajan duro para imprimir algo nuevo en el universo.
- themgt
> Puedes implementar la lógica de tu servidor directamente en la base de datos
> Puedes hacer uso del Trabajo Licenciado siempre que tu aplicación o servicio use el Trabajo Licenciado con no más de una instancia de SpacetimeDB en producción y siempre que no uses el Trabajo Licenciado para un Servicio de Base de Datos.
Por lo tanto, como producto OSS, SpacetimeDB no escala.