ParticleDB от Orkes позиционируется как база для AI-агентов: транзакционный SQL, key-value, векторный поиск и аналитика в одном движке, написанном на Rust. На главной странице красовались надписи «Full ACID» и «formally proven» — со ссылкой на доказательство на TLA+. Кайл Кингсбери из Jepsen проверил это на версиях с 1.1.4 по 1.1.18.11-rc.22 и нашёл 96 проблем. Почти все — на одном сервере, с одним клиентом и без сбоев.
Что именно ломалось
Среди находок есть смешные и есть страшные. Ограничение NOT NULL игнорировалось: строка с NULL вставлялась, но становилась частично невидимой — SELECT * её не показывал, а COUNT(*) считал. UNIQUE тоже не работал, а UPDATE умел создать несколько строк с одинаковым первичным ключом.
Предикаты жили своей жизнью: SELECT * FROM t WHERE 4 = 5 возвращал строку, потому что любое равенство трактовалось как поиск по первичному ключу. Внутри транзакции запрос с WHERE a = 1 мог вернуть строку со значением 2. Удалённые строки продолжали учитываться в агрегатах, а часть строк нельзя было ни обновить, ни удалить.
Главное — не это. В режиме occ, который стоит по умолчанию, база теряла уже закоммиченные записи при обычной работе, а в serializable, самом строгом режиме, Jepsen зафиксировал Lost Update и внутренние аномалии.
Что с этим делать
Orkes выпустила 1.1.19-rc.13 и утверждает, что оставшиеся проблемы закрыты. Отчёт финансировала сама Orkes, и это стоит держать в голове при чтении, хотя методология Jepsen от заказчика не зависит. Вывод простой: база молодая, проверяйте её на своих сценариях, а не на обещаниях.
ParticleDB, built by Orkes, markets itself as a database for AI agents: transactional SQL, key-value, vector search and analytics in one Rust engine. Its home page advertised “Full ACID” and “formally proven”, the latter pointing at a TLA+ proof. Kyle Kingsbury of Jepsen tested versions 1.1.4 through 1.1.18.11-rc.22 and documented 96 issues. Most appeared on a single server, with a single client and no faults.
What actually broke
Some findings are funny, some are alarming. NOT NULL was ignored: a NULL row could be inserted and then became partly invisible — SELECT * did not show it while COUNT(*) counted it. UNIQUE did not work either, and an UPDATE could produce several rows with the same primary key.
Predicates had a life of their own: SELECT * FROM t WHERE 4 = 5 returned a row, because any equality was treated as a primary-key lookup. Inside a transaction, a query with WHERE a = 1 could return the row holding 2. Deleted rows still showed up in aggregates, and some rows could be neither updated nor deleted.
That is not the worst of it. In occ, the default mode, the database lost committed writes during normal operation, and in serializable, the strictest setting, Jepsen observed Lost Update and internal anomalies.
What to do
Orkes has released 1.1.19-rc.13 and says the remaining issues are resolved. Orkes also funded the research, which is worth keeping in mind while reading, though Jepsen’s methodology does not bend to a client. The conclusion is simple: the database is young — test it against your own workloads rather than its promises.