IndexedDB формально стандартизирована, однако поведение на практике
заметно расходится между браузерными движками. Эти различия затрагивают
производительность, устойчивость транзакций, квоты хранилища, работу с
бинарными данными, а также нюансы жизненного цикла базы данных. При
использовании через абстракции вроде localForage эти особенности
становятся менее заметны, но полностью не исчезают, поскольку драйвер
IndexedDB лишь оборачивает нативное API.
Общая специфика
IndexedDB как стандарта
IndexedDB представляет собой транзакционную,
событийно-ориентированную объектную базу данных, работающую асинхронно в
рамках origin. Несмотря на стандартизацию:
- реализация зависит от движка (Blink, Gecko, WebKit);
- политики хранения контролируются браузером;
- лимиты и эвикция (удаление данных) определяются не стандартом, а
политикой платформы.
Ключевой момент: одинаковый код может вести себя по-разному в
разных браузерах без изменения логики приложения.
Chrome и Chromium-браузеры
Производительность и
стабильность
В браузерах на основе Chromium (Chrome, Edge, Opera) IndexedDB
наиболее стабильна и производительна:
- быстрые записи больших объёмов данных;
- хорошая оптимизация транзакций;
- предсказуемое поведение cursor и index scan.
Особенность: движок Blink использует оптимизированный уровень поверх
LevelDB, что даёт стабильную латентность при больших объёмах.
Работа с большими объектами
Chromium хорошо справляется с:
- Blob и ArrayBuffer;
- сериализацией структурированных объектов;
- потоковой записью больших значений.
Однако при частых мелких транзакциях возможны:
- блокировки очереди транзакций;
- деградация производительности при отсутствии батчинга.
Квоты и хранение
- хранение зависит от доступного дискового пространства;
- применяется quota-based модель;
- при нехватке места возможна эвикция данных без явного
уведомления.
Важно: в Chromium данные IndexedDB обычно удаляются только при
критическом давлении на хранилище.
Firefox (Gecko)
Архитектура хранения
Firefox использует собственную реализацию поверх SQLite-подобной
архитектуры. Это приводит к отличиям:
- более строгая консистентность транзакций;
- медленнее массовые записи по сравнению с Chromium;
- высокая стабильность при конкурентных операциях.
Особенности транзакций
В Firefox:
- транзакции более строго изолированы;
- чаще проявляются задержки при блокировке object store;
- ошибки
TransactionInactiveError возникают
предсказуемее, но чаще при неправильном использовании.
Политика хранения данных
Firefox имеет более агрессивные политики приватности:
- может запрашивать разрешение на persistent storage;
- активнее участвует в эвикции при low storage conditions;
- режимы приватного просмотра полностью изолируют IndexedDB.
Поведение в приватном режиме
В private browsing:
- IndexedDB может работать в memory-only режиме;
- данные исчезают после закрытия сессии;
- поведение отличается от Chromium, где изоляция менее строгая.
Safari (WebKit)
Наиболее проблемная
реализация
Safari исторически имеет наиболее специфичное поведение
IndexedDB:
- частые баги с квотами;
- нестабильность при больших базах;
- ограничения на длительное хранение.
7-дневное правило
Ключевая особенность:
- данные IndexedDB могут быть удалены через ~7 дней
неиспользования;
- особенно в условиях low storage;
- пользователь может не получать явного уведомления.
Это делает Safari непригодным для сценариев, где требуется
долгосрочное offline-хранилище без серверной синхронизации.
Ограничения на storage
- строгие ограничения на общий размер данных;
- более агрессивная эвикция по сравнению с Chromium и Firefox;
- чувствительность к iCloud storage оптимизациям.
WebKit транзакционные
особенности
- больше случаев неожиданного abort транзакций;
- нестабильность при конкурентных операциях;
- возможные проблемы с cursor iteration при больших наборах
данных.
iOS и WKWebView
Контекст приложений
IndexedDB в WKWebView (iOS приложения):
- может очищаться системой при нехватке памяти;
- не гарантирует долговечность данных;
- зависит от режима приложения (foreground/background).
Особенности хранения
- storage может сбрасываться при обновлении приложения;
- данные могут очищаться при системной оптимизации;
- поведение отличается от Safari на macOS.
Различия в квотах и эвикции
Модель Chromium
- soft quota, зависящая от диска;
- эвикция только при необходимости;
- предсказуемое расширение хранилища.
Firefox
- quota более консервативная;
- активное участие user-facing политик;
- возможны ограничения при отсутствии persistent storage.
Safari
- самая агрессивная эвикция;
- зависимость от системного storage pressure;
- возможное удаление «холодных» данных.
Поведение транзакций в
разных движках
Chromium
- транзакции длиннее по времени;
- допускается высокая параллельность чтения;
- запись блокирует только конкретный object store.
Firefox
- строгая последовательность выполнения;
- блокировки возникают быстрее;
- выше вероятность ожиданий при конкурентных write-операциях.
Safari
- нестабильные long-running transactions;
- возможные silent abort;
- чувствительность к event loop нагрузке.
Особенности сериализации
данных
Structured Clone Algorithm
Все браузеры используют structured clone, но с нюансами:
- Chromium: наиболее полная поддержка типов (Blob, Map, Set);
- Firefox: строгая реализация, но стабильная;
- Safari: исторически ограниченная поддержка некоторых edge-case
структур.
Blob и File
- Chromium: оптимизированное хранение без лишнего копирования;
- Firefox: стабильное, но медленнее при больших объёмах;
- Safari: возможны проблемы при частых операциях трансформации.
Различия в версии базы
данных
Обновление схемы (versioning)
- Chromium: быстрое выполнение
onupgradeneeded;
- Firefox: более строгий контроль версий;
- Safari: иногда требует повторного открытия соединения после
upgrade.
Конкурентное открытие базы
Различия проявляются при:
- нескольких вкладках;
- одновременном доступе;
- фоновых сервис-воркерах.
Safari и Firefox чаще вызывают VersionError или
блокировку upgrade при активных соединениях.
Влияние сервис-воркеров
Chromium
- стабильная интеграция;
- IndexedDB доступен из SW без значимых ограничений.
Firefox
- поддержка полная, но с более строгими таймингами жизни воркера;
- возможны задержки при пробуждении.
Safari
- нестабильное поведение при фоновых воркерах;
- возможны потери соединения с IndexedDB при suspend/resume.
Поведение в условиях
нехватки места
Chromium
- постепенная эвикция;
- уведомления через ошибки quota;
- попытка сохранить критичные данные.
Firefox
- агрессивная очистка non-persistent storage;
- зависимость от permission persistent storage.
Safari
- наиболее агрессивная стратегия очистки;
- возможное удаление базы целиком.
Практическое
влияние на абстракции вроде localForage
localForage скрывает различия через единый API, но:
- скорость операций всё равно зависит от движка;
- стабильность хранения определяется браузером;
- эвикция данных не контролируется библиотекой;
- различия особенно заметны при больших объёмах и offline-first
сценариях.
Критические последствия:
- нельзя полагаться на «вечное» хранение данных;
- необходимо учитывать возможность silent loss;
- требуется стратегия повторной синхронизации.
Свод ключевых различий
- Chromium: максимальная стабильность и производительность
- Firefox: строгая консистентность и умеренная скорость
- Safari: агрессивные ограничения и нестабильность хранения
- iOS WKWebView: системные ограничения и возможная потеря данных
Поведенческие
паттерны, влияющие на архитектуру приложений
Различия IndexedDB напрямую формируют архитектурные решения:
- необходимость кэширования поверх IndexedDB;
- использование серверной синхронизации как источника истины;
- периодическая валидация локальных данных;
- отказ от предположения о постоянстве storage.
На практике это приводит к модели, где IndexedDB рассматривается как
ускоряющий слой, а не как гарантированное
долговременное хранилище.