LatticeDB совместил графовую БД, векторный и текстовый поиск в одном файле

LatticeDB, открытый встраиваемый (embedded) движок графовой базы данных: вся база, один переносимый файл, без отдельного сервера и настройки. Он совмещает в одном Cypher-подобном языке запросов три способа работы с одними и теми же данными: обход графовых связей, поиск по векторному сходству (алгоритм HNSW) и полнотекстовый поиск с ранжированием BM25. Через тот же файл проходит и журнал событий, именованные потоки с явным смещением читателя и поток изменений графа (changefeed) используют тот же путь транзакций и журнала упреждающей записи (WAL), что и обычные записи в граф. Модель локальная: один процесс-владелец и один писатель на машину.

Установка CLI, однострочный curl-скрипт; есть биндинги для Python (pip install latticedb), TypeScript/Node.js (npm install @hajewski/latticedb) и Go (через cgo). В примере из документации на одном графе создаются документы, фрагменты текста и авторы, для фрагментов сохраняются векторные эмбеддинги и строится полнотекстовый индекс, после чего этот граф опрашивается тремя способами: векторным поиском (оператор <=> в запросе), полнотекстовым поиском (оператор @@) и обычным обходом связей. Для демонстрации без внешних сервисов используется встроенная функция hash_embed, это детерминированный «заглушечный» эмбеддинг, а не семантический: похожий по смыслу текст не даёт близкие вектора, поэтому порог расстояния для него произволен, а запрос на схожесть может вообще ничего не найти. Для настоящей семантики документация советует подключить реальную модель, упомянута поддержка HTTP-клиента для Ollama или OpenAI.

Производительность авторы замеряли сами на Apple M1, в один поток, с автоматически масштабируемым пулом буферов. Кэшированный поиск узла по B+-дереву занимает 0,13 микросекунды, по их словам, это уровень RocksDB в памяти и в 23 раза быстрее SQLite на диске. Векторный поиск по HNSW на 1 млн векторов даёт среднее время 0,83 миллисекунды при 100% полноте (recall) для топ-10; упаковка страниц связей в HNSW-индексе снижает память примерно в 4,5 раза, а само время поиска растёт медленнее линейного (O(log N)) при полноте 99, 100% для топ-10. Полнотекстовый поиск на инвертированном индексе с BM25-ранжированием, по заявлению проекта, примерно в 300 раз быстрее, чем FTS5 в SQLite, и сопоставим по скорости с Tantivy, специализированной библиотекой полнотекстового поиска на Rust. В тестах обхода графа (BFS с кэшем смежности и битовой картой посещённых узлов у LatticeDB против рекурсивного CTE с дедупликацией через UNION у SQLite) на выборках в 10 тысяч и 100 тысяч узлов оба движка находят одно и то же множество достижимых узлов (около 8 тысяч в тесте с ограничением глубины), но разрыв в скорости растёт с глубиной обхода из-за накладных расходов рекурсивного CTE.

Сам проект в документации оговаривает: строго голова к голове, на одном железе и в одном тестовом стенде измерены только сравнения с SQLite; цифры для конкурирующих графовых баз Kuzu и Neo4j взяты из сторонних публикаций с другим железом и неконтролируемой методикой, и предлагается воспринимать их лишь как ориентир по порядку величины, а не как результат бенчмарка.

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

LatticeDB, встраиваемая графовая база в одном файле, совмещающая обход графа, векторный поиск HNSW и полнотекстовый поиск BM25 в одном Cypher-подобном языке запросов.
Модель локальная, однопроцессная, с одним писателем; события и изменения графа идут через тот же WAL-журнал, что и обычные транзакции.
Есть биндинги для Python, TypeScript/Node.js и Go; CLI ставится curl-скриптом.
Собственные бенчмарки на Apple M1: 0,13 мкс на кэшированный поиск узла, 0,83 мс на векторный поиск среди 1 млн векторов при 100% recall, полнотекстовый поиск примерно в 300 раз быстрее SQLite FTS5.
Проект сам предупреждает: только сравнения с SQLite измерены на одном стенде, цифры для Kuzu и Neo4j, из сторонних источников и лишь ориентировочны; встроенный демо-эмбеддинг не семантический, для реальной работы нужна настоящая модель.

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

Для локальных ИИ-приложений, агентной памяти, RAG-пайплайнов, персональных баз знаний, обычно приходится поднимать отдельно графовую СУБД, отдельно векторную базу и отдельно полнотекстовый поисковик и синхронизировать их между собой. LatticeDB предлагает держать все три способа доступа к данным в одном локальном файле и одном языке запросов, без отдельного сервера, тот же принцип, что сделал популярным SQLite для реляционных данных, только для графов, векторов и текста разом.

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

Разработчикам локальных и встраиваемых приложений, тем, кто строит персональные ассистенты, инструменты для заметок и каталогов, графы цитирования, память ИИ-агентов и RAG-пайплайны и не хочет разворачивать для этого отдельные серверы вроде Neo4j, Weaviate или Elasticsearch. Проект также позиционирует себя как лёгкую альтернативу Neo4j и Weaviate для прототипирования на одной машине.

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

Установка, однострочный curl-скрипт для CLI, pip install latticedb для Python, npm install @hajewski/latticedb для TypeScript/Node.js, биндинги для Go через cgo. Запросы пишутся на Cypher-подобном языке: оператор <=>, векторное расстояние, оператор @@, полнотекстовый поиск, плюс обычные MATCH/WHERE/RETURN для обхода графа. В комплекте есть заглушечная функция эмбеддингов hash_embed для тестов без внешних сервисов; для реальной семантики документация советует подключить настоящую модель эмбеддингов, включая HTTP-клиент для Ollama или OpenAI.

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

Все цифры производительности, собственные замеры проекта на Apple M1 в один поток, независимой проверки нет. Сам проект оговаривает границы: сравнения с SQLite измерены голова к голове на одном стенде, а цифры для конкурирующих графовых баз Kuzu и Neo4j взяты из сторонних публикаций на другом железе с неконтролируемой методикой, их стоит читать как ориентир по порядку величины, а не как результат бенчмарка. В источнике нет ни версии, ни лицензии, ни сведений о том, сколько LatticeDB в разработке и готов ли он к продакшену.

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

Модель, один процесс, один писатель на локальной машине: это не распределённая и не многопользовательская база, конкурентную запись из нескольких процессов она не поддерживает. Встроенная функция эмбеддингов в примерах, детерминированная заглушка, а не семантическая модель: у похожего по смыслу текста векторы могут оказаться совсем не близкими, и поиск по сходству с ней способен не найти вообще ничего. Судя по отсутствию версии и лицензии в источнике, проект молодой, а зрелость и стабильность API пока не подтверждены.