El artículo analiza el lanzamiento de SpacetimeDB 2.0, una base de datos que integra también lógica de aplicación, y examina tanto su arquitectura como la estrategia de marketing de sus creadores. El autor critica la comparativa de rendimiento publicada por el equipo de SpacetimeDB: considera que no es honesta, ya que enfrenta un producto de naturaleza muy distinta —un almacén en memoria con código ejecutándose dentro de la propia base de datos— frente a sistemas distribuidos, multi-región y altamente disponibles, que requieren saltos de red para cada consulta. La diferencia, explica, es comparable a comparar una extensión vectorial transaccional como la que él mismo desarrolló en PlanetScale contra pgvector en una máquina con más datos que memoria: sale ganando, pero no es una comparación justa.
En el plano técnico, el texto describe el modelo de almacenamiento de SpacetimeDB como esencialmente una tabla hash protegida por un único Read-Write Mutex (del crate parking_lot), donde todas las escrituras se ejecutan de forma secuencial bajo ese cerrojo global. Esa arquitectura garantiza la linearizabilidad de forma trivial, pero introduce un problema no resuelto: la política de prioridad entre lectores y escritores queda como detalle de implementación, sin una semántica documentada ni configurable, lo que puede provocar inanición de los lectores bajo cargas intensivas de escritura.
El autor contrapone esta estrategia con la de proyectos como Turbopuffer, que prefieren documentación técnica sobria y benchmarks realistas para ganarse la confianza del mercado, y argumenta que, más allá del revuelo, SpacetimeDB necesitaría una explicación clara de sus compromisos de diseño si quiere atraer usuarios serios.