Где хранить данные мобильного приложения в России
Хранение данных — это не только выбор облака. Нужно понять, какие данные собираются, где база, кто имеет доступ, как делаются резервные копии и что требует 152-ФЗ.
Данные мобильного приложения для российского рынка обычно стоит планировать вокруг серверной части, базы данных, резервных копий, доступа команды, аналитики и требований 152-ФЗ. Если приложение собирает персональные данные граждан РФ, нужно заранее проверить, где физически хранится база, какие внешние сервисы получают данные, как устроены журналы, резервное копирование, удаление аккаунта и передача данных третьим лицам.
Подготовьте запрос на оценку приложения через практичные вопросы
Отметьте нужные функции: аккаунты, корзину, платежи, админку, интеграции, хранение данных и запуск.
Главные выводы
- Хранение данных нужно проектировать до разработки, а не после выбора дизайна.
- Важно знать не только основную базу, но и резервные копии, журналы, аналитику, поддержку и внешние интеграции.
- Для персональных данных российских пользователей проверьте требования локализации и фактическое место хранения.
- Готовая серверная платформа ускоряет MVP, но может не подойти по требованиям хранения, контроля и будущего роста.
- Чем больше ролей, платежей, документов и интеграций, тем важнее собственная понятная серверная архитектура.
Что именно нужно хранить
| Данные | Примеры | Где возникают риски |
|---|---|---|
| Профиль пользователя | имя, телефон, email, фото, настройки | персональные данные, доступ поддержки |
| Бизнес-объекты | заказы, записи, уроки, услуги, товары | статусы, история изменений, ошибки |
| Платежи | сумма, статус, чек, возврат | связь с провайдером, бухгалтерия, споры |
| Геолокация | адрес, координаты, маршрут, зона доставки | лишний сбор данных, работа в фоне |
| Файлы | фото, документы, домашние задания, аватары | хранение, доступ, удаление |
| Журналы | ошибки, действия админа, события безопасности | нельзя писать лишние личные данные |
Серверная часть, база и файлы
Мобильное приложение редко хранит все важное только на телефоне. Обычно есть серверная часть: она отвечает за вход, роли, данные, платежи, уведомления, админ-панель и связь с внешними сервисами. База хранит структурированные данные: пользователей, заказы, записи, товары, уроки, статусы. Файловое хранилище держит изображения, документы, видео или вложения.
Для MVP можно использовать готовые платформы и облачные сервисы, если они подходят по требованиям. Но важно заранее проверить регион хранения, доступы, резервные копии, выгрузку данных и ограничения. Если продукт растет, появляется несколько ролей, сложные платежи, админ-панель, персональные данные и интеграции, часто выгоднее проектировать более контролируемую серверную часть.
Что означает российская локализация данных
В 152-ФЗ есть требования, которые могут влиять на хранение персональных данных российских пользователей. Для владельца приложения главный практический вывод такой: нельзя выбирать облако только потому, что разработчикам удобно. Нужно понимать, где физически находится база, где резервные копии и какие внешние сервисы получают данные.
Проверьте:
- регион основной базы;
- регион резервных копий;
- где хранятся файлы пользователя;
- куда отправляется аналитика;
- какие данные получает служба поддержки;
- какие данные получает платежный провайдер;
- есть ли передача данных за пределы России;
- как оформлены согласия и политика.
Некоторые российские облачные провайдеры отдельно описывают соответствие требованиям 152-ФЗ, например страницы по безопасности и соответствию у Yandex Cloud или Selectel. Но даже если провайдер заявляет подходящую инфраструктуру, конкретный продукт все равно нужно проверять: что именно вы храните, как настроены сервисы и кто имеет доступ.
Почему Firebase или зарубежное облако не всегда подходят
Firebase, Supabase и похожие сервисы удобны для быстрой разработки: авторизация, база, файлы, уведомления, аналитика. Для прототипа это может быть сильным ускорением. Но для российского приложения с персональными данными нужно отдельно проверить регион, договорные условия, передачу данных, журналы, резервные копии и требования конкретного бизнеса.
Проблема не в названии сервиса. Проблема в том, что владелец продукта должен понимать, где лежат данные и можно ли это подтвердить. Если проекту нужна строгая российская инфраструктура, сложные роли, особые журналы, интеграции с 1C/CRM, платежами и админ-панелью, готовая платформа может стать временным решением, которое позже придется менять.
Есть идея приложения и нужен трезвый следующий шаг?
Разобрать идею приложенияДоступы и админ-панель
Хранение данных — это еще и вопрос доступа. Кто видит клиентов? Может ли менеджер скачать базу? Может ли поддержка открыть историю платежей? Кто меняет заказ? Кто удаляет аккаунт? Видит ли разработчик реальные данные на тестовом стенде?
Для админ-панели заранее задайте роли:
- владелец;
- администратор;
- менеджер поддержки;
- бухгалтер;
- контент-менеджер;
- провайдер или исполнитель;
- разработчик на тестовом окружении.
Каждой роли нужны только свои действия. Если всем дать полный доступ, приложение может пройти запуск, но риск ошибок и утечек будет расти вместе с командой.
Резервные копии и удаление данных
Резервные копии часто забывают в обсуждении 152-ФЗ. Но если данные удаляются из основной базы, что происходит с копиями? Как долго они хранятся? Кто может восстановить? Как отличить случайное удаление от запроса пользователя?
В первой версии не нужно строить сложную корпоративную систему, но нужно иметь понятную политику:
- Что сохраняется в резервной копии.
- Как часто делается копия.
- Где она хранится.
- Кто имеет доступ.
- Как проверяется восстановление.
- Что происходит при удалении аккаунта.
Для бизнеса это не абстрактная безопасность. Это способность восстановить заказы, записи, платежи и доступ пользователей после ошибки.
Как Appfyl проектирует хранение данных
Мы начинаем с карты данных и ролей. Для приложения доставки это клиент, курьер, администратор, заказ, адрес, статус и платеж. Для клиники — пациент, запись, врач, результаты, уведомления и доступы. Для онлайн-школы — ученик, курс, урок, прогресс, домашнее задание и оплата.
После этого выбирается серверная архитектура: где база, где файлы, где админ-панель, какие внешние сервисы подключаются, какие события аналитики нужны и что нельзя отправлять наружу. Такой подход помогает оценивать не "облако вообще", а конкретный объем работ.
Для MVP Appfyl обычно попадает в диапазон 1-1,5 млн рублей. Если нужна простая база и несколько сценариев, это может остаться в первой версии. Если нужны персональные данные, роли, интеграции, платежи, резервные копии, аудит действий и отдельная инфраструктура, проект чаще попадает в диапазон 1,5-3,5 млн рублей или выше.
Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.
Используйте эти выводы, чтобы собрать реалистичную первую версию.
Оценить MVPПревратите исследование в план запуска
Appfyl поможет превратить идею в понятный план приложения, список функций первой версии и план первых работ.
Обсудить план приложенияПолезные ссылки
Частые вопросы
Для простых офлайн-инструментов иногда можно. Но если есть аккаунт, синхронизация, платежи, записи, заказы, админ-панель или несколько устройств, нужна серверная часть.
Архитектура. Облако — это место и набор сервисов. Архитектура описывает, какие данные где живут, кто имеет доступ, как работает резервная копия, аналитика и удаление.
Не всегда. Для MVP можно использовать готовые сервисы, если они подходят по требованиям. Но нужно заранее понимать, что будет при росте продукта и требованиях к хранению.
Где находится база, где файлы, где резервные копии, какие данные уходят во внешние сервисы, кто имеет доступ к админ-панели, как удаляется аккаунт и что пишется в журналы.
Опишите роли, данные, платежи, файлы, интеграции, требования к российскому хранению и сценарии удаления. Это можно начать через [интерактивный бриф Appfyl](/ru/tools/app-cost-calculator/).