Как хранить данные небольшого проекта: SQLite, PostgreSQL или файлы

Когда я впервые всерьёз столкнулся с выбором хранилища для парсера объявлений о недвижимости, решение упиралось не в «какая база круче», а в простой вопрос: что не превратится в источник боли через три‑шесть месяцев. До этого я годами проектировал серверную часть для мобильных приложений и инди‑игр, где данные часто помещались в локальные файлы или простую базу. Рынок недвижимости добавил свои особенности: сырые JSON‑ответы от досок объявлений, частая дедупликация по внешним идентификаторам, агрегация цен по районам и бесконечные выгрузки для ручной проверки.

Для прототипа, личного сервиса или небольшого SaaS реальных вариантов по‑прежнему три: файлы, SQLite и PostgreSQL. Ниже — практический разбор без абстракций: где каждый вариант хорош, где начинает ломаться и как выбрать без архитектурной магии.

Что вообще значит «хранить данные» в небольшом проекте

Хранение данных — это не один большой ящик, а несколько разнородных потоков. В проектах автоматизации недвижимости это особенно заметно: вы одновременно тянете исходные страницы, приводите объявления к единой схеме, считаете средние цены и отдаёте результаты пользователям. Чтобы не смешивать всё в кучу, удобно разделить данные по типам:

• Бизнес‑данные — объявления, пользователи, заявки, цены, статусы обработки, события.
• Служебные данные — логи, кэш, очереди задач, метрики, временные файлы.
• Файлы — JSON, CSV, изображения, выгрузки, вложения, отчёты.

На практике одна и та же система почти всегда использует несколько способов хранения одновременно. Например, в парсере объявлений:

• метаданные держите в базе;
• исходные выгрузки (сырые HTML, ответы API) складываете в файлы или object storage;
• кэш и временные результаты не храните вообще или чистите по TTL.

Главная ошибка — пытаться засунуть всё в одну корзину, будь то один огромный JSON или одна таблица, которая раздувается до неприличия. Для небольшого проекта такая унификация часто не только не нужна, но и вредна: она усложняет миграции и замедляет поиск.

Короткий вывод: что выбрать в большинстве случаев

Если нужен быстрый старт, один сервер и мало одновременных записей — берите SQLite. Если проект уже живёт в сети, есть несколько пользователей, фоновые задачи и рост нагрузки — смотрите в сторону PostgreSQL. Если данные простые, редкие и не требуют запросов по множеству условий — можно хранить их в файлах, но только осознанно, а не потому что «так быстрее набросать».

В проектах анализа недвижимости я чаще всего встречаю такую цепочку: личный парсер начинается с SQLite, затем при появлении веб‑морды и фоновых воркеров переезжает на PostgreSQL. Файлы остаются для сырых выгрузок и отчётов. Это экономит время и не мешает росту.

Таблица сравнения: файлы, SQLite и PostgreSQL

Таблица даёт общий ориентир, но выбор всегда зависит от характера нагрузки. Для парсера, который раз в 15 минут сохраняет пачку из пары сотен объявлений, SQLite будет почти неотличима по скорости от PostgreSQL. А вот для аналитического дашборда с десятками одновременных читателей и постоянным обновлением цен PostgreSQL уже не избыточен.

Когда файлы — нормальное решение

Файлы часто недооценивают. Я сам долгое время скептически относился к хранению в JSON, пока не понял, что для ряда задач это самый прозрачный и дешёвый способ. Файловое хранение отлично работает, если данные:

• небольшие по объёму;
• редко изменяются;
• не требуют сложной фильтрации;
• удобно читаются как целиком;
• нужны скорее как конфиг, кэш или выгрузка.

В контексте недвижимости файлы спасают при работе с сырыми ответами от API застройщиков или досок объявлений: сохранить JSON‑ответ на диск проще, чем сразу нормализовывать и раскладывать по таблицам. Но это работает до тех пор, пока вам не нужно искать по цене, району или статусу.

Хорошие сценарии для файлов

• список ссылок на объявления в JSON;
• временный кэш парсинга;
• выгрузка в CSV для ручной обработки аналитиком;
• конфигурация проекта;
• результаты пакетной обработки;
• локальные черновики и сниппеты страниц для отладки.

Например, когда нужно быстро проверить, что API отдаёт корректные поля, я часто скидываю ответ в файл и смотрю на него в любом редакторе. Никакая база не даст такой скорости обратной связи.

Когда файлы начинают мешать

• нужно искать данные по нескольким полям;
• появляется параллельная запись;
• нужен контроль уникальности (например, по external_id объявления);
• надо делать транзакции;
• возникают конкурирующие процессы;
• важно не потерять часть данных при падении процесса.

Предположим, у вас несколько воркеров парсят разные разделы доски объявлений и одновременно дописывают результаты в общий JSON. Рано или поздно один процесс перезапишет данные другого или файл окажется повреждён. Уведомления о пропавших записях в продакшене — плохой способ узнать об этом.

Типовые проблемы файлового хранения

• дубли записей при повторном запуске парсера без проверки существующих;
• повреждение файла при одновременной записи из двух процессов;
• сложность обновления одного элемента внутри большого файла (нужно перезаписывать весь файл);
• ручная реализация индексации и поиска;
• нет нормальной истории изменений — только бэкапы целиком, если вы о них позаботились.

Практическое правило

Если у вас больше одного процесса, который может писать в один и тот же файл, — это уже тревожный сигнал. Если появляется необходимость «что‑то дописать в середину» или «удалить один объект из списка», обычно пора уходить в базу. Файлы хороши как конечный слепок данных, а не как рабочее хранилище с конкурентным доступом.

Когда SQLite — лучший старт

SQLite — это не «игрушечная база», а очень практичный выбор для небольших проектов. Она хранит всё в одном файле, не требует отдельного сервера и поддерживает полноценный SQL. Для личного парсера объявлений или внутреннего инструмента агента это часто идеальный баланс между простотой и возможностями.

SQLite подходит, если:

• проект маленький, но уже не совсем одноразовый;
• нужен один файл с данными;
• приложение запускается на одном сервере;
• запись идёт из одного процесса или из небольшого числа процессов;
• важно быстро начать без DevOps;
• нужен офлайн‑режим или локальное хранение.

Я не раз использовал SQLite для офлайн‑калькуляторов ипотеки и локальных баз объявлений, которые агент мог просматривать без интернета. Один файл легко синхронизировать, бэкапить и переносить на другой носитель.

Сильные стороны SQLite

• почти нулевая настройка;
• один файл легко бэкапить и переносить;
• отлична для MVP и внутренних инструментов;
• поддерживает SQL, индексы, связи, транзакции;
• подходит для большинства личных проектов и небольших сервисов.

При работе с объявлениями SQLite позволяет строить нормальные индексы по цене, району и дате обновления. Этого достаточно, чтобы быстро фильтровать сотни тысяч записей, если запросы простые и не требуют полнотекстового поиска или геоаналитики.

Ограничения SQLite, о которых забывают

Главное ограничение SQLite — конкурирующие записи. Чтение она переваривает очень хорошо, но запись остаётся узким местом: фактически одновременно пишет один writer, а остальные ждут. В режиме WAL чтения и записи живут спокойнее, но модель с одним пишущим потоком никуда не исчезает.

Это означает:

• для редких обновлений SQLite удобна;
• для частых параллельных insert/update она начинает тормозить;
• при высокой конкуренции возможны ошибки занятости базы;
• если резко вырастет число записей, придётся мигрировать.

Отдельно стоит упомянуть настройки `busy_timeout` и `journal_mode=WAL`. Они не устраняют ограничение одного писателя, но снижают вероятность ошибок «database is locked» при умеренной нагрузке. Я часто выставляю busy_timeout в несколько секунд для парсеров, которые пишут пачками.

Хороший пример из практики

Если проект парсит объявления раз в несколько минут и сохраняет их пачками, SQLite обычно справляется отлично. Например, один cron‑процесс забирает 200 объявлений с доски, дедуплицирует по external_id и вставляет новые записи в одной транзакции. Такая нагрузка для SQLite — как разминка. Если же у вас десятки фоновых воркеров, веб‑запросы и постоянные обновления статусов, PostgreSQL уже выглядит безопаснее.

Когда нужен PostgreSQL

PostgreSQL стоит брать не потому, что «так делают серьёзные проекты», а когда появляется реальная потребность в устойчивой многопользовательской записи, развитой аналитике и росте. Для сервисов аналитики цен на недвижимость, где одновременно работает несколько пользователей и фоновые задачи постоянно обновляют базу, PostgreSQL снимает целый класс проблем, с которыми SQLite справляется только костылями.

PostgreSQL нужен, если:

• несколько процессов одновременно пишут в базу;
• есть веб‑приложение с ростом трафика;
• нужна сложная аналитика и фильтрация;
• важны роли, права, ограничения, триггеры;
• планируются миграции, фоновые очереди, интеграции;
• проект может быстро вырасти из «маленького».

Например, когда вы строите агрегатор цен по районам и хотите строить геозапросы, PostgreSQL с расширением PostGIS или хотя бы JSONB‑полями даёт инструменты, которых в SQLite просто нет из коробки. Триггеры и ограничения помогают поддерживать целостность данных при массовых импортах из разных источников.

Сильные стороны PostgreSQL

• хорошо работает при высокой конкуренции;
• поддерживает сложные запросы и агрегации;
• удобен для командной разработки;
• лучше подходит для долгоживущих сервисов;
• богаче по типам данных и возможностям;
• проще строить вокруг него зрелую архитектуру.

Отдельно отмечу материализованные представления для пересчёта средних цен по районам или статусам объявлений. В PostgreSQL можно пересчитывать такие агрегаты по расписанию, не нагружая основные запросы. Это сильно упрощает аналитические дашборды.

Когда PostgreSQL может быть лишним

• проект совсем маленький;
• данных мало и они редко меняются;
• нет желания поднимать отдельный сервис;
• нужен простой локальный инструмент;
• важна минимальная сложность поддержки.

Иными словами, PostgreSQL — это не всегда «лучше». Иногда он просто слишком тяжёлый для задачи, где хватило бы файла или SQLite. Поднимать отдельный сервер ради списка из сотни объявлений — это переусложнение, которое съест время на администрирование и не даст выгоды.

Как выбрать: простой алгоритм

Алгоритм выбора сводится к трём шагам, которые я сам прохожу перед стартом любого проекта.

Шаг 1. Ответьте на три вопроса

• Сколько у вас процессов будут писать данные?
• Нужно ли делать сложные запросы и фильтры?
• Сколько времени вы готовы тратить на поддержку хранилища?

Шаг 2. Сопоставьте ответы

• 1 процесс, мало данных, быстрый старт → файлы или SQLite.
• 1–2 процесса, SQL‑запросы, нужен порядок → SQLite.
• несколько писателей, рост, команда, интеграции → PostgreSQL.

Шаг 3. Оцените будущий рост

Если через несколько месяцев вероятны:

• авторизация пользователей;
• уведомления;
• аналитика цен;
• фоновые задачи;
• интеграции с CRM или API;

лучше не закапываться в файловое хранение. Перевод проекта с файлов на БД почти всегда дороже, чем сразу начать с SQLite или PostgreSQL. В моей практике миграция с JSON‑файлов на SQLite занимала больше времени, чем хотелось бы, именно из‑за необходимости вычищать дубли и вручную восстанавливать целостность.

Что хранить в базе, а что — в файлах

Хорошая архитектура часто гибридная. В проектах сбора данных о недвижимости я обычно разделяю слои: быстрая база для оперативных данных и файловое/объектное хранилище для сырья и артефактов.

В базе храните:

• пользователей;
• объекты недвижимости;
• статусы обработки;
• связи между сущностями;
• истории изменений;
• результаты фильтрации;
• очереди задач;
• признаки дедупликации.

В базе должны жить данные, которые нужно искать, связывать, обновлять по частям и контролировать на уникальность. Для объявления это может быть ID, внешний ID, цена, площадь, локация, статус, дата публикации. По этим полям строятся индексы и выполняются аналитические запросы.

В файлах храните:

• сырые выгрузки;
• большие JSON‑ответы;
• отчёты;
• резервные дампы;
• временные артефакты;
• изображения и документы, если это не ядро логики.

Сырые HTML‑страницы или ответы API часто занимают много места и нужны только для повторного парсинга или отладки. Держать их в базе — значит раздувать её до гигабайтов и замедлять резервное копирование. Лучше складывать их в файлы или object storage, а в базе хранить только ссылки и метаданные.

Удобный принцип

Если данные нужно искать, связывать, агрегировать или обновлять по частям, они должны жить в базе. Если данные нужно хранить как целый объект и редко трогать, файл может быть лучше. Это простое правило экономит много времени при проектировании.

Пошаговый план выбора хранилища для проекта

1. Выпишите типы данных проекта.
2. Отметьте, что нужно искать и фильтровать.
3. Определите, сколько процессов будут писать одновременно.
4. Посчитайте, как часто данные обновляются.
5. Оцените стоимость миграции через полгода.
6. Выберите самое простое решение, которое не сломается при ближайшем росте.

Звучит банально, но именно эта последовательность уберегает от преждевременной оптимизации. Когда я только начинал автоматизировать сбор объявлений, то пропустил пункт 5 и застрял на JSON‑файлах. Позже пришлось потратить несколько вечеров на переписывание под SQLite и восстановление порядка.

Типовые ошибки

Ошибка 1. Начинать с JSON «потому что быстро»

JSON удобен в начале, но быстро превращается в боль, если нужны:

• дедупликация;
• поиск;
• сортировка;
• частичное обновление;
• отчётность.

В парсинге объявлений дедупликация по внешнему ID возникает уже на второй день, и JSON без нормальной индексной структуры заставляет либо перебирать все записи в коде, либо мигрировать.

Ошибка 2. Брать PostgreSQL «на вырост» без причины

Сложная инфраструктура раньше времени даёт лишнюю нагрузку:

• настройка;
• бэкапы;
• пользователи и права;
• мониторинг;
• миграции;
• обслуживание.

Для локального инструмента, которым пользуется один агент, PostgreSQL будет просто отнимать время на администрирование без заметной пользы. Я не раз видел проекты, где «серьёзная база» была нужна скорее для ощущения солидности, чем для реальных задач.

Ошибка 3. Слишком долго сидеть на SQLite при росте записи

SQLite отлично работает, пока запись не становится узким местом. Если начинает расти число параллельных обновлений, не стоит героически «дожимать» её костылями. Увеличение busy_timeout, ретраи и переезд на WAL откладывают проблему, но не решают её. Когда фоновых воркеров становится несколько десятков, пора всерьёз смотреть на PostgreSQL.

Ошибка 4. Хранить большие файлы внутри базы без необходимости

Если объекты тяжёлые, а база нужна для метаданных, лучше отделить сами файлы от структуры данных. BLOB‑поля в SQLite или bytea в PostgreSQL раздувают базу, замедляют запросы и усложняют резервное копирование. Для изображений планировок или PDF отчётов надёжнее использовать файловую систему или object storage, а в базе хранить только путь.

Практические рекомендации по сценарию

Для личного проекта

• начните с SQLite;
• держите данные в нормальной схеме, а не в одном огромном JSON;
• сразу продумайте миграцию на PostgreSQL, если появится рост.

Даже если проект кажется одноразовым, нормальная схема в SQLite занимает ненамного больше времени, чем свалка в JSON, а будущие манипуляции с данными становятся на порядок проще.

Для небольшого веб‑сервиса

• если есть авторизация, фоновые задачи и несколько пользователей — лучше PostgreSQL;
• если сервис одиночный и нагрузка мала — SQLite допустима.

Для сервиса с одновременными пользователями и фоновым обновлением цен PostgreSQL снимает большинство проблем конкурентного доступа. SQLite можно оставить для внутренней админки или single‑user инструмента.

Для парсера и автоматизации

• сырые ответы складывайте в файлы или object storage;
• нормализованные сущности — в SQLite или PostgreSQL;
• если много параллельных задач, PostgreSQL безопаснее.

Типичный пайплайн: воркер скачивает страницу, сохраняет сырой HTML в файл, извлекает поля, нормализует и пишет в базу. При одном воркере достаточно SQLite. При распределённом парсинге с несколькими агентами и общей очередью задач лучше сразу проектировать вокруг PostgreSQL, чтобы не упираться в блокировки записи.

Чек‑лист перед выбором

• ☐ Есть ли параллельная запись?
• ☐ Нужно ли делать сложные фильтры?
• ☐ Понадобятся ли транзакции?
• ☐ Будет ли проект жить дольше пары недель?
• ☐ Нужны ли бэкапы и восстановление?
• ☐ Появятся ли пользователи и роли?
• ☐ Может ли проект вырасти в сервис?

Если на большинство вопросов ответ «да», файлы уже не лучший вариант. Если параллельная запись и пользователи — явные перспективы, ориентируйтесь на PostgreSQL. В остальных случаях SQLite будет разумным стартом.

Итог

Для небольшого проекта нет универсального ответа, но есть здравый порядок выбора. Файлы подходят для простых, редких и почти неизменяемых данных. SQLite — лучший старт для маленького, но уже живого проекта с SQL и минимальной инфраструктурой. PostgreSQL нужен тогда, когда появляется конкурирующая запись, рост нагрузки, аналитика и требования к устойчивости.

Самый частый практический выбор такой: сначала SQLite, затем PostgreSQL по мере роста. Это экономит время, сохраняет простоту на старте и не мешает вырасти в нормальный сервис. Главное — не пропустить момент, когда SQLite начинает становиться узким местом, и не строить с самого начала огромную инфраструктуру ради одного парсера.

FAQ

Что лучше для старта: SQLite или PostgreSQL?

Для старта почти всегда проще SQLite, если нет высокой конкуренции записи и сложной инфраструктуры. PostgreSQL стоит поднимать, когда уже есть несколько параллельных писателей или веб‑приложение с реальными пользователями.

Можно ли хранить всё в JSON‑файлах?

Можно, если данных мало и запросы простые. Но при росте поиск, обновления и контроль качества становятся неудобными. Для объявлений с ценами и фильтрами JSON быстро превращается в узкое место, особенно при дедупликации и построении отчётов.

Когда SQLite становится тесной?

Когда много одновременных записей, несколько процессов конкурируют за данные или появляются требования к более сложной серверной архитектуре. Частые `database is locked` и растущее время ответа при записи — первые сигналы к миграции.

Почему PostgreSQL не стоит брать всегда?

Потому что это лишняя сложность для маленького проекта, где достаточно одного файла и простого SQL‑хранилища. Обслуживание сервера, пользователи, права, мониторинг и бэкапы требуют времени, которое на раннем этапе лучше потратить на функциональность.

Что выбрать для парсера объявлений?

Если парсер один и пишет не слишком часто — SQLite. Если несколько воркеров, фоновые задачи и рост нагрузки — PostgreSQL. Сырые ответы всегда можно держать в файлах или object storage, а в базе хранить только нормализованные данные.