Hacker News Digest

Почему мы отказались от WatermelonDB

• IndexedDB тормозит: WatermelonDB держит всю БД в памяти через LokiJS, что при 100 МБ+ данных недопустимо.
• Синхронизация хрупкая: клиент обязан сначала вытянуть данные, иначе мутации могут затереться.
• Проект замедлился: PR с чанковой загрузкой висит месяцами, активность упала.
• Web-ограничения: IndexedDB единственное постоянное хранилище в браузере, и все реализации страдают от его скорости.

Что мы искали

• Полноценная работа офлайн: чтение, удаление, ответ, сортировка писем без сети.
• Сотни МБ и миллионы строк с первого запуска — задача из топ-1 %.
• Кроссплатформенность: web + натив, общий знаменатель — браузер.
• Отказались от идеи «база-независимый API»: готовы интегрироваться на уровне Postgres, если это даст надёжность.

Первые кандидаты

Библиотека	Плюсы	Минусы
WatermelonDB	Open-source, проверен временем	Память, тормоза, слабая поддержка
PowerSync	Есть self-host	Требует кластер MongoDB + изменения Postgres, кейсы только демо
ElectricSQL	Переписывают, односторонняя синхронизация, требует Postgres

Итог
Альфа-версия на WatermelonDB работала, но к ноябрю стало ясно: для «тяжёлого» офлайна нужно что-то совсем другое. Мы начали поиск «новой волны» решений, отбросив все предубеждения.

• Автор поста (isaachinman) доволен Replicache+Orama, ждёт стабильности Zero, считает InstantDB созревшей, а Triplit теперь просто open-source.
• Критика: почти все решения (WatermelonDB, ElectricSQL, InstantDB, Convex) всё равно сидят на IndexedDB, который сам по себе «хак» и в Chrome построен на SQLite.
• Появляется надежда на Origin Private File System (OPFS) и WASM-SQLite, но пока боятся коррупций и нестабильности.
• Разработчики жалуются: мало примеров разрешения семантических конфликтов, ограниченные типы SQLite, сложности больших данных (ГБ+) и неясность, где open-source, а где нет.

Automerge — это движок синхронизации данных с приоритетом локальной работы, упрощающий создание коллаборативных приложений. Выпущена версия 3.0.

Главное обновление — резкое снижение потребления памяти. Ранее хранение полной истории документов могло приводить к гигабайтам в ОЗУ. В 3.0 память сокращена более чем в 10 раз (иногда значительно больше), что делает Automerge применимым в куда большем числе сценариев.

Также упразднены избыточные API, особенно при работе со строками.

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

Чтобы узнать, как достигнуты улучшения, читайте далее.

• Улучшенное использование памяти

  • Automerge хранит каждое изменение для офлайн-работы, конфликтов и истории; это требует большого объёма метаданных.
  • Раньше: сжатый колоночный формат «на диске», но при загрузке в память — несжатый вид, из-за чего ОЗУ раздувалось.
  • Теперь: сжатое представление используется и во время выполнения, давая огромную экономию. Пример: вставка «Моби Дика» — было ~700 МБ в v2, стало ~1,3 МБ в v3.
  • Меньше памяти — стабильнее нагруженные сервера синхронизации.
  • Для документов с длинной историей существенно ускорена загрузка (пример: с «не загрузилось за 17 часов» до 9 секунд).

• Упрощение API

  • Два типа строк: «коллаборативные» (сливают правки) и «неколлаборативные».
  • В 1.0: обычные строки для неколлаборативных, класс Text — для коллаборативных.
  • В 2.0 (namespace next): сделали коллаборативный текст по умолчанию — строки для него, RawString для неколлаборативного.
  • В 3.0: закрепили новый подход — удалён Text, API next стал дефолтным; RawString переименован в ImmutableString.

• Попробовать

  • Automerge 3.0 используется по умолчанию в последних @automerge/automerge-repo и @automerge/react (версия 2.1.0).
  • Новичкам — туториал. Существующим кодовым базам — руководство по миграции; если зависите от @automerge/automerge-repo, выполните npm update @automerge/automerge.
  • Проблемы — создавайте issue; вопросы — в Discord.

• Обсуждение вокруг Automerge 3.0: многие впечатлены скачком производительности и «local‑first» подходом к CRDT; сравнивают с Yjs, ElectricSQL, Convex, Zero и интересуются бенчмарками.
• Ключевой апгрейд: сжатое представление данных теперь используется на рантайме — память и время загрузки резко снижены (пример: «Моби Дик»: ~700 МБ → ~1,3 МБ в v3).
• Вопросы по применимости: когда выбирать Automerge/Yjs (совместное редактирование, rich text) vs ElectricSQL (сервер — источник истины, синхронизация приложения). Также интерес к настройкам для «одиночной» кросс‑девайс синхронизации.
• Технические вопросы: структура полурешётки, тип регистра карт (MV-Register vs LWW), поддержка перемещений в деревьях, permissioned-блоки в документе, интеграция с TipTap/ProseMirror, терминальные UI, C/Rust API и состояние C-обёртки.
• Ответы/подсказки: TipTap можно использовать, обернув схему атрибутами Automerge; undo/redo меняется соответствующим образом; ссылки на конфликты в доках; перемещения в деревьях прототипировались (Клепманн), но, похоже, ещё не в основном релизе.
• Практические интересы: какие железо/серверные ресурсы нужны для синка и сколько чтений/записей выдержит; запрос бенчмарков против Yjs и рекомендации по альтернативам (jsonjoy для перформанса).
• Сообщество делится опытом кастомных CRDT, типобезопасностью, бизнес‑правилами и тем, как это вписать в Automerge; часть аудитории всё ещё ищет простое объяснение, «что именно делает» инструмент.