# Переход с SQLite на PostgreSQL

## Зачем

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

`PostgreSQL` нужен как следующий уровень серверной БД для более надёжной конкурентной записи, более предсказуемой работы под нагрузкой и дальнейшего роста проекта.

## Что сделать

- Подготовить план переноса серверной БД с `SQLite` на `PostgreSQL`.
- Найти все места, где код завязан на особенности `SQLite`.
- Проверить все DAO и SQL-запросы на совместимость с `PostgreSQL`.
- Продумать схему миграции существующей production/test базы без потери данных.
- Отдельно проверить транзакции, `UPSERT`, индексы, case-insensitive сравнения и миграции схемы.
- После этого подготовить отдельный этап внедрения и переключения сервера.

## Что уже есть в коде

- Доступ к БД в основном проходит через DAO-слой, а не полностью размазан по проекту.
- Основная серверная логика уже разделена по модулям.
- Но SQL и миграции сейчас написаны под `SQLite` и потребуют отдельного прохода.

## Откуда продолжать

- Начать с инвентаризации всех DAO и схемы БД.
- После этого сделать отдельный документ с оценкой объёма работ по переносу.
- Затем решить, будет ли это:
  - полный перевод сервера на `PostgreSQL`;
  - или поддержка двух драйверов на переходный период.

## Что потом обновить

- Серверную документацию по БД и миграциям.
- Инструкции по локальному запуску сервера.
- Скрипты деплоя и настройки окружения.

## Что временно отключено и что вернуть потом

- В серверном runtime временно снята проверка `channelName must not contain only digits`
  в `SHiNE-server/shine-server-db/src/main/java/shine/db/channels/ChannelNameRules.java`.
- Причина: на боевой истории уже есть блоки с числовыми именами каналов, и сервер
  должен уметь с нуля восстановить `blockchain_state` и `.bch`, подтягивая старые
  блоки от других sync-серверов.
- Что осталось как текущее поведение:
  - UI по-прежнему не даёт создать новый канал только из цифр;
  - сервер принимает такие имена, чтобы не ломать replay старых блоков.
- Что нужно сделать отдельным следующим шагом:
  - вернуть серверное продуктовое правило для новых каналов;
  - сделать это совместимо со старой историей, чтобы импорт/реплей существующих
    блоков не падал на старых числовых channel name.
- Какие документы обновить при возврате:
  - `docs/libs/shine-server-bd/POSTGRES_RUNTIME_SCHEMA_V1.md`;
  - UI/серверные документы по правилам имён каналов, если появится отдельная спецификация.
- С какого сценария продолжать:
  - повторить cold start тест на `t2`: пустая PostgreSQL schema, удалённые `.bch`,
    новый запуск, ожидание полной синхронизации от `t1`/`t3`.
- Последняя полная рабочая точка с этим временным компромиссом:
  - ветка `migration-postgres`, коммит будет создан после этой записи.