SpacetimeDB 2.0 уличили в нечестных бенчмарках

На своей странице (материал датирован 26 февраля 2026 года) инженер под ником vmg, по данным его профиля, ведущий системный инженер (Principal Systems Engineer), ранее работавший в GitHub (2010-2020) и PlanetScale (2020-2025), а с 2025 года, согласно тому же профилю, в месте, обозначенном как «SpaceXAI (via Cursor)», разбирает запуск версии 2.0 базы данных SpacetimeDB. Компания отметила релиз шуточным маркетинговым видео, где конкурентов сравнивают со «слезами» (обыгрывается фраза «пьём слёзы конкурентов»), и опубликовала собственные бенчмарки, в которых конкуренты выглядят слабо: даже значок лупы стоит рядом с худшими результатами на графике, «чтобы разглядеть, насколько они плохи». Автор прямо называет это неприятным ходом, но говорит, что хочет разобрать сам продукт и его бенчмарки максимально честно.

Его исходный тезис в том, что бенчмарки SpacetimeDB «слишком хороши, чтобы быть правдой», и это буквально так: они нечестные. У них есть и чисто технические изъяны в том, что именно они измеряют: автор ссылается на альтернативный набор бенчмарков (кто их составил, не уточняется), где SpacetimeDB, напротив, показывает себя намного хуже конкурентов. Но главный изъян глубже: SpacetimeDB, по мнению автора, продукт совсем другого типа, чем базы данных, с которыми её сравнивают, поэтому само сравнение изначально нечестное, даже если по-человечески понятно, почему компания его выбрала.

Пример нечестного сравнения автор берёт из собственного опыта в PlanetScale: несколько лет назад команда выпустила расширение для MySQL для поиска похожих векторов, полностью транзакционное, с векторными данными на диске под управлением буферных пулов MySQL. Это сильно отличалось от более простых решений вроде pgvector, которые используют структуру HNSW и требуют, чтобы граф похожести целиком помещался в оперативной памяти. Было соблазнительно взять инстанс EC2 с 32 ГБ оперативной памяти, загрузить в него 64 ГБ векторных данных и сравнить с тем же самым на Postgres с pgvector: на одной и той же машине, с одним и тем же набором данных и теми же запросами расширение PlanetScale отрабатывало десятки тысяч запросов в секунду, а pgvector отвечал на такой же запрос больше 3 секунд, потому что граф HNSW постоянно подкачивался с диска. По словам автора, из этого можно было бы сделать эффектный заголовок «мы быстрее pgvector в 10 000 раз», но команда этого не сделала, потому что сравнение нечестное: продукты решают разные задачи на разных условиях. Вместо громкого числа PlanetScale опубликовала технический разбор своей реализации без нечестных сравнений, и его хорошо приняли.

Второй пример честного подхода автор находит в Turbopuffer: у него не самые впечатляющие бенчмарки, а в документации больше строк про то, чего база не умеет, чем про то, что умеет. Но все и так знают: если задача подходит под его нишу поиска, лучше продукта на рынке нет. По формулировке автора, Turbopuffer «не пьёт слёзы конкурентов, а просто тихо забирает их клиентов».

Возвращаясь к SpacetimeDB: это база данных и сервер приложений в одном. Вы разворачиваете инстанс базы, а код вашего приложения выполняется прямо внутри неё (что-то вроде хранимых процедур в реляционной СУБД, но с более удобной средой разработки). Именно поэтому в бенчмарках по числу запросов в секунду (QPS) она обгоняет распределённые многорегиональные базы данных, с которыми её сравнивают: конкурентам приходится делать отдельный сетевой запрос на каждую операцию, а у SpacetimeDB сети между приложением и данными нет вовсе. Показывать в маркетинге именно это автор считает не очень удачной идеей: доступ к данным в памяти быстрее доступа по сети, и компания просто построила стенд, который это доказывает. С точки зрения потенциального клиента это не производит впечатления.

Дальше следует сама техническая часть, которой, по словам автора, нет в документации SpacetimeDB. Всё зафиксированное состояние базы данных в инстансе защищено одним-единственным Read-Write Mutex (мьютексом чтения-записи) на всю базу целиком. Все записи идут строго последовательно, поэтому линеаризуемость системы, по выражению автора, «доказывается тривиально»: вся система, по сути, хеш-таблица с одним замком перед ней. Две записи никогда не выполняются одновременно и потому не могут конфликтовать, но одновременно не могут выполняться и чтение с записью. Сам мьютекс представляет собой готовое решение parking_lot::RWMutex из одноимённого крейта Rust (порт исходного WTF::Lock из WebKit) с «отложенной справедливостью»: читатели рано или поздно получают доступ к блокировке даже при высокой нагрузке на запись, но могут быть случайно задержаны на срок до 0,5 мс.

Во время записи, пока держится глобальная блокировка, среда выполнения Wasmtime исполняет «редьюсеры» (reducers): произвольный пользовательский код, скомпилированный в WebAssembly. Пока редьюсер работает, ни один другой редьюсер не может писать в базу, и никакой другой код вообще не может из неё читать. Официальная документация прямо говорит, что редьюсеры «не могут выполнять HTTP-запросы»: по мнению автора, это совершенно логично, раз критическая секция для всех записей монопольная и полностью последовательная. Есть лазейка: «процедуры» (Procedures), которые на момент выхода версии 2.0 всё ещё в статусе беты (в документации оговорено, что API может измениться): они как раз позволяют делать «дорогие» операции вроде HTTP-запросов. Но если внутри процедуры открыть транзакцию, она снова захватывает тот же глобальный мьютекс и блокирует любые параллельные чтения и записи, поэтому коммитить её нужно очень быстро, иначе вся система встанет. Для чтения используются «представления» (Views), аналог редьюсеров, но только для чтения: поскольку они берут блокировку на чтение, несколько представлений могут выполняться параллельно друг с другом, но пока идёт хотя бы одно представление, писать в базу нельзя.

SpacetimeDB целиком хранит данные в оперативной памяти: на диск ничего не пишется синхронно как часть транзакции. У базы есть журнал упреждающей записи (Write-Ahead Log, WAL), но он асинхронный и сбрасывается на диск в фоне периодически, по умолчанию раз в 50 мс. Писать WAL полностью синхронно при таком устройстве системы нельзя: это остановило бы вообще все чтения и записи. Для тех, кому всё же нужна гарантия, что прочитанное действительно на диске, есть флаг withConfirmedReads: он заставляет чтение «уснуть» на сервере, пока не увидит на диске нужные записи WAL. Задержка может доходить до 50 мс, и это, как признаёт сам автор, очень долго для одного запроса. Логика компромисса в том, что SpacetimeDB рассчитана на «в основном эфемерные» данные, для которых такая строгая гарантия обычно и не нужна.

Автор сравнивает происходящее с историей MongoDB 2011 года: тогда Mongo тоже вышла с не очень качественной базой, но с эффектными бенчмарками. Над ней долго издевались, включая известный ролик «MongoDB is Web Scale», пока компания не купила движок хранения WiredTiger и не довела продукт до ума. Спустя пятнадцать лет, по словам автора, Mongo стала серьёзной и жизнеспособной базой данных, но часть технических специалистов до сих пор помнит первые годы и отказывается ставить её в прод, хотя это представление устарело. Вывод автора таков: в 2026 году, если бы он сам запускал продукт, базу данных, по сути являющуюся хеш-таблицей с одним замком, он делал бы это тихо, ведь «срезать углы» при запуске базы данных, как показал успех MongoDB, это рабочая стратегия (сам он выбрал бы иначе), но только пока не приходится расплачиваться разом и техническим, и репутационным долгом. А маркетинговое видео «с лазерами и бутылкой слёз» эту расплату сильно осложняет.

По масштабированию SpacetimeDB не является распределённой системой в полном смысле, и у неё жёсткий потолок по масштабируемости и доступности. Можно развернуть «кластер SpacetimeDB»: один основной инстанс и несколько реплик-последователей с эвентуально согласованной репликацией. Но вся система всё равно упирается в ресурсы CPU и оперативной памяти той машины, где крутится основной инстанс: там же исполняется весь код приложения, и туда же целиком должны помещаться в память все данные базы. Если объём данных превысит объём оперативной памяти, откажет всё сразу, и база, и приложение, потому что это одно и то же. Масштабировать можно только вертикально: нужна более мощная машина. По оценке автора, эти компромиссы честные и годные, но они делают SpacetimeDB скорее «более мощным Redis», чем «более производительной реляционной базой данных», и ему непонятно, зачем компания вообще сравнивает себя со вторым.

Изначально SpacetimeDB разрабатывалась как бэкенд для многопользовательской онлайн-игры (MMORPG), в которую, по словам автора, прямо сейчас можно играть в Steam. Под такую задачу, считает он, все технические решения выглядят разумно: если запись о том, что игрок подобрал легендарный предмет, попадёт на диск с задержкой в 50 мс, а не мгновенно, ничего страшного. Но студий, разрабатывающих MMORPG, сейчас немного, а крупные обычно строят собственные бэкенды, поэтому автор понимает, зачем компания перепозиционирует SpacetimeDB во второй версии на более широкую аудиторию. Маркетинговая страница теперь заявляет: «С SpacetimeDB языковые модели продвигаются намного дальше, потому что база берёт на себя всё хранение данных, логику, развёртывание и синхронизацию в реальном времени в едином связном бэкенде», имея в виду агентный кодинг, то есть разработку, в которой код пишут ИИ-агенты. Автор называет этот выбор рынка объяснимым («именно это сейчас и происходит»), но прямо говорит: с технической точки зрения для этой задачи выбраны буквально худшие из возможных решений.

Причина в том, что вся производительность и доступность как приложения, так и базы данных на 100% зависят от коротких фрагментов пользовательского кода (редьюсеров и процедур), которые не должны иметь побочных эффектов или зависать. Но это не проверяется системой типов, а зависит от конкретного WASM-байткода, который на лету создаёт JIT-компилятор. Любая ошибка внутри такой критической секции, скорее всего, проявится только в проде и способна снизить производительность всего приложения вплоть до отказа доступности. Отсюда ироничный вывод автора: это не самая подходящая среда для того, чтобы в ней языковая модель писала код.

При этом автор подчёркивает: продукт и правда интересный, и уроки из него можно извлечь. Он допускает, что в гипотетической версии 3 создатели SpacetimeDB могли бы изолировать пользовательский код так, чтобы он не мешал остальным операциям, разрешить транзакциям идти столько, сколько нужно, не влияя на производительность других, вводить неявный троттлинг для слишком долгих операций, сделать систему по-настоящему распределённой, чтобы ИИ-агенту не приходилось самому проектировать распределённую систему, и в целом запускаться с меньшим числом сомнительных бенчмарков и куда более подробной технической документацией. Именно такой продукт, заключает автор, стоило бы держать в поле зрения.

Ключевые факты

SpacetimeDB выпустила версию 2.0 с шуточным маркетинговым видео («слёзы конкурентов») и собственными бенчмарками, которые технический разбор называет нечестными.
Автор разбора, инженер vmg (ранее GitHub 2010-2020 и PlanetScale 2020-2025, сейчас в SpaceXAI), показывает: SpacetimeDB сравнивают с распределёнными базами данных совсем другого класса, хотя это по сути база данных и сервер приложений в одном, где код приложения выполняется прямо внутри базы.
Технически всё состояние базы в инстансе защищено одним глобальным мьютексом чтения-записи: запись строго последовательна, а чтение и запись не могут идти параллельно; пользовательский код («редьюсеры») выполняется в Wasmtime (WebAssembly) внутри этой же критической секции и не может делать HTTP-запросы.
База данных полностью в оперативной памяти; журнал (WAL) сбрасывается на диск асинхронно, по умолчанию раз в 50 мс, а флаг withConfirmedReads может задержать чтение до 50 мс ради гарантии сохранности. Масштабирование только вертикальное: машина помощнее, а не распределённый кластер.
Автор сравнивает ситуацию с MongoDB 2011 года и утверждает: нынешние технические решения SpacetimeDB меньше всего подходят именно для того рынка, на который компания сейчас нацелилась, агентного кодинга с помощью языковых моделей.

Почему это важно

Материал показывает, как именно устроен маркетинговый обман бенчмарками: не общими словами «бенчмарки врут», а конкретной технической причиной, сравнением продуктов из разных весовых категорий с разными компромиссами. Это показательный кейс на фоне бума СУБД и инфраструктурных стартапов для ИИ-агентов: чем громче маркетинг («слёзы конкурентов», лупа над «проигравшими»), тем нужнее независимый разбор архитектуры вместо пересказа пресс-релиза. Отдельно материал важен потому, что SpacetimeDB именно сейчас позиционирует себя как бэкенд для агентного кодинга (разработки с помощью языковых моделей), а автор показывает: её ключевое архитектурное решение, единый глобальный мьютекс на всю базу, плохо сочетается именно с этим сценарием использования.

Кому это важно

Инженерам и архитекторам, которые выбирают базу данных или бэкенд для приложения, особенно если рассматривают SpacetimeDB или похожие продукты «база плюс сервер приложений в одном». Тем, кто использует WebAssembly-рантаймы вроде Wasmtime для встроенной пользовательской логики. Командам, которые сами публикуют бенчмарки и хотят делать это честно (в тексте два примера для подражания: технический разбор PlanetScale и документация Turbopuffer). А также всем, кто сейчас выбирает инфраструктуру под ИИ-агентов и агентный кодинг и рискует купиться на маркетинг вместо архитектуры.

Как это применить

Проверяйте любой вендорский бенчмарк на вопрос: тот же ли это класс продукта с теми же компромиссами? Если нет, число неинформативно, каким бы эффектным оно ни было. Если рассматриваете конкретно SpacetimeDB, учитывайте: все чтения и записи в инстансе идут через один глобальный мьютекс чтения-записи, поэтому параллельная запись невозможна в принципе, а параллельно с записью нельзя даже читать; пользовательский код (редьюсеры и процедуры) выполняется прямо внутри этой критической секции и не должен зависать или делать блокирующие вызовы вроде HTTP (на момент разбора это гарантирует лишь документация, а не система типов); данные живут только в оперативной памяти, WAL сбрасывается на диск раз в 50 мс, и если нужна гарантия «прочитанное точно на диске», используйте withConfirmedReads, закладывая на это до 50 мс задержки; масштабирование только вертикальное (мощнее машина), распределённого масштабирования вширь нет. Если публикуете собственные бенчмарки, возьмите пример с PlanetScale и Turbopuffer: показывайте архитектуру и границы применимости, а не эффектные проценты против продукта другого класса.

Можно ли доверять

Автор не анонимен: на странице указаны ник (vmg), должность (Principal Systems Engineer) и трудовой путь: GitHub (2010-2020), PlanetScale (2020-2025), а с 2025 года, по данным того же профиля, место, обозначенное как «SpaceXAI (via Cursor)». Технические утверждения о том, как устроена SpacetimeDB, подкреплены прямыми цитатами из официальной документации и маркетинговой страницы компании. При этом сама статья датирована 26 февраля 2026 года, а на Hacker News это обсуждение появилось лишь спустя примерно полгода, в августе 2026 года: источник никак не объясняет этот разрыв, поэтому часть деталей (например, нахождение «Процедур» в статусе беты) отражает состояние продукта на момент выхода версии 2.0, а не обязательно текущее. Ни разработчик SpacetimeDB, ни автор «альтернативного набора бенчмарков», на который ссылается материал, в тексте статьи по имени не названы, и нет сведений о том, ответила ли компания на этот разбор публично.

Риски и подводные камни

Для тех, кто уже строит на SpacetimeDB: вся производительность и доступность приложения зависят от того, что ни один редьюсер и ни одна процедура никогда не зависнут и не вызовут по сети что-то долгое, а это не проверяется на уровне типов, только по факту в проде. Одна неудачная попытка, и деградация или отказ грозят всему приложению разом, потому что критическая секция общая. Рост данных за пределы оперативной памяти машины ломает всё, потому что горизонтального масштабирования нет, только апгрейд железа. Отдельный риск в сценарии «ИИ-агент пишет код на SpacetimeDB»: по мнению автора, лучший кандидат на то, чтобы случайно сгенерировать долгую или блокирующую операцию внутри общей критической секции, это как раз код, сгенерированный языковой моделью, а не написанный вручную опытным инженером. То есть продукт целится именно в ту аудиторию, для которой его нынешняя архитектура подходит хуже всего. И более широкий риск для читателей вообще: приём «сравнить бенчмарками принципиально разные по устройству продукты» не уникален для SpacetimeDB, это распространённый приём маркетинга в базах данных (пример: MongoDB в 2011 году), и доверять эффектным цифрам без понимания архитектуры не стоит.

«С SpacetimeDB языковые модели продвигаются намного дальше, потому что база берёт на себя всё хранение данных, логику, развёртывание и синхронизацию в реальном времени в едином связном бэкенде.»

— маркетинговая страница SpacetimeDB, процитированная в обзоре