Это отличный стратегический поворот. Если мы не ограничены слабым железом RPi3, наши возможности сильно расширяются. Давай разберем все твои варианты: тесты, вендор-лок (привязку к БД) и облака.
1. Насколько мы привяжем себя к PostgreSQL (Vendor Lock-in)?
Если мы используем нативный ENUM и VARCHAR[] (массивы), мы действительно жестко привязываем структуру БД к PostgreSQL.
- Ты не сможешь просто взять и запустить этот же SQL-скрипт создания таблиц в MySQL, SQLite или H2. Он выдаст ошибку синтаксиса.
- Однако, современные ORM (например, SQLAlchemy в Python) умеют сглаживать эти углы. Они могут сказать: “Если база — Postgres, используй
VARCHAR[], а если SQLite — автоматически сериализуй список в JSON-строку”. - Но на уровне “сырых” SQL-запросов и аналитики, если ты привыкнешь использовать специфичные функции Postgres (например,
UNNEST()для разворачивания массивов), перенос логики на другую СУБД потребует переписывания запросов.
2. Базы данных для тестов (H2 / SQLite vs PostgreSQL)
Использовать In-Memory базы (типа H2 или SQLite в памяти) для тестов — это подход, который был очень популярен лет 5-10 назад.
Современный стандарт индустрии — это Testcontainers (или Docker Compose для тестов). Как это работает:
- Ты запускаешь тесты (E2E или интеграционные).
- Тестовый фреймворк автоматически за 1-2 секунды поднимает настоящий, пустой контейнер с PostgreSQL в Docker.
- Прогоняются все тесты (с использованием массивов, ENUM’ов и любых фишек Postgres).
- Контейнер уничтожается.
Почему это лучше, чем H2: Если ты тестируешь на H2, а в продакшене крутится Postgres, рано или поздно ты поймаешь баг: тест пройдет успешно, а на реальном сервере упадет из-за разницы в диалектах SQL или поведении транзакций. Тестировать нужно на том же движке, который работает в бою.
3. Облачные базы данных (Free Tiers)
Здесь есть суровая математика. Мы подсчитали, что 10 миллионов партий займут около 50-60 ГБ. Почти все популярные “модные” облачные базы (Supabase, Neon.tech, Render) дают в бесплатном тарифе максимум 500 МБ. Этого хватит только на этапе прототипа (~100 000 партий), но не для твоих планов.
Твой спаситель в облаках — Oracle Cloud (Always Free).
Кстати, в твоей документации (AGENTS.md) я видел упоминание: “deployment configurations for Homelab / Oracle Cloud”.
Oracle предоставляет абсолютно безумный бесплатный тариф:
- До 4 ARM-ядер (или 2 AMD)
- До 24 ГБ оперативной памяти
- До 200 ГБ дискового пространства (Block Volume)!
Ты можешь бесплатно развернуть на Oracle Cloud свой собственный сервер PostgreSQL. На 200 ГБ влезет 30-40 миллионов партий со всеми индексами. Ни один другой облачный провайдер не дает столько бесплатно.
4. Старый ПК (4 ГБ, HDD) vs Локальная разработка
- Старый ПК: 4 ГБ памяти для PostgreSQL на staging (тестовом) сервере — это более чем достаточно. Медленный HDD скажется только на сложных аналитических запросах с агрегацией по всем 10 миллионам строк, но для обычной игры или поиска конкретной позиции разницы с SSD ты почти не заметишь (база будет кешировать индексы в оперативной памяти).
- Локально: Поднять PostgreSQL через Docker на твоем Mac — это одна команда (
docker run ... postgres).
Итоговая рекомендация архитектора:
- Идем “All In” в PostgreSQL. Забываем про совместимость с SQLite/H2 на уровне таблиц. Смело используем
ENUMиVARCHAR[]. Это сделает архитектуру чище и производительнее. - Тесты: Переходим на Testcontainers (запуск эфемерного Postgres в Docker для E2E и интеграционных тестов).
- Хостинг БД:
- Production Analytics: Твой локальный ASUS сервер (SSD 128GB).
- Staging: Старый ПК (4GB, HDD).
- Cloud Backup/Web API: Поднять бесплатную виртуалку на Oracle Cloud с их 200 ГБ диском.
Если такой план развития инфраструктуры тебе по душе, мы можем оставить в схеме нативные типы Postgres (Массивы и ENUM) с чистой совестью!