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, а где нет.

Начав использовать Linear, я углубился в «локально-ориентированные» приложения: клиент хранит полную БД, изменения сначала пишутся локально, а фоновый sync-рантайн рассылает их по WebSocket/GraphQL. Пользователь видит мгновенные обновления без сетевой задержки.

Проанализировав реверс-инжиниринг и доклады команды Linear, я понял: их sync-движок — это месяцы работы, чтобы решить офлайн-режим, конфликты, частичную синхронизацию, миграции схем и безопасность.

В 2025-м экосистема уже готова:

• Electric SQL — Postgres-синхронизация
• PowerSync — корпоративный уровень
• Jazz — «обновляешь локальный state — всё синхронизируется»
• Zero, Instant, Triplit, LiveStore — упрощают разработку

Jazz предлагает CoValues: схема на Zod + автоматическая репликация. Пример:

const Post = co.map({
  title: z.string(),
  comments: co.list(Comment)
});

Меняешь post.title — изменение мгновенно отражается у всех участников.

• Участники обсуждают преимущества и недостатки подходов local-first (Zero, Electric, Jazz, CRDT, PouchDB, Turso и др.).
• Ключевые плюсы: мгновенный UX, офлайн-работа, упрощённая синхронизация через запросы (Zero) и отсутствие конфликтов (CRDT).
• Минусы: рост данных, проблемы разрешения конфликтов, сложность прав и миграций, ограниченная поддержка SSR-ценящих разработчиков.
• Некоторые считают, что SSR всё ещё важен для первой загрузки, но не решает офлайн/коллаборацию.
• Подводный камень: большинство инструментов заточены под веб, хотя мобильные сценарии офлайна выглядят более естественными.