Database upgrade debt: как «работает — не трогай» превращает базу данных в бизнес-риск

Production-база обычно стареет тихо. Во многих командах приложение может деплоиться часто, зависимости регулярно обновляются, инфраструктура проходит через несколько minor-релизов, а PostgreSQL, MySQL, MariaDB или MongoDB остаются на версии, выбранной годы назад. Аргумент звучит разумно: база работает, инцидентов нет, клиенты не жалуются, значит риск менять выше риска оставить как есть.

Проблема в том, что у базы данных долг копится не только в бинарнике сервера. Он расползается в драйверы, ORM, расширения, replication topology, backup tooling, миграционные скрипты, cloud-provider policies и знания конкретных инженеров. В какой-то момент вопрос «когда обновимся?» превращается в другой: «можем ли мы вообще безопасно обновиться, если завтра аудит, CVE, рост cloud bill или провайдер заставит нас двигаться?»

В сентябре 2026 Percona опубликовала 2026 State of Open Source Database Management Report. По официальному анонсу, исследование проводилось Censuswide в июле 2026 среди 300 U.S.-based DBA, SRE и platform engineers, работающих с PostgreSQL, MySQL, MongoDB, Redis или Valkey (Percona report, press release). На публичной странице отчёта акценты ожидаемые для инфраструктуры: cost, performance, security/compliance, vendor lock-in, AI readiness. Например, 31% респондентов называют rising cloud spend главным барьером к снижению database TCO, 42% — inefficiency/slow throughput главным performance challenge, 54% — vendor lock-in как препятствие адаптации к меняющимся regulatory requirements.

Отдельный инфоповод — цифра 97% по obsolete/end-of-support database software. Её важно атрибутировать аккуратно: в доступной публичной HTML-странице Percona эта цифра не была видна в research, но её вынесли медиа со ссылкой на отчёт. TechRadar пишет, что, по данным Percona, 97% U.S. database administrators работают с устаревшим software, а DigitalToday формулирует это как 97% респондентов, чьи организации эксплуатируют хотя бы часть database versions за пределами поддержки; там же упоминается 44%, сообщивших о значительной доле таких баз (TechRadar, DigitalToday). Это не нужно читать как глобальную статистику по всем компаниям мира. Но как сигнал для SaaS и SMB это полезно: проблема массовая именно потому, что database upgrade — не «apt upgrade», а stateful change с бизнес-последствиями.

Что на самом деле входит в database upgrade debt

Когда команда говорит «у нас старый MySQL» или «мы всё ещё на PostgreSQL 13», это только верхний слой. Реальный dependency graph обычно шире.

В него входят:

• версия ядра СУБД: major/minor, community или provider build;

• расширения и плагины: PostgreSQL extensions, MySQL authentication plugins, MariaDB storage-engine особенности, MongoDB Feature Compatibility Version;

• драйверы и клиенты: JDBC, libpq/psycopg, MongoDB drivers, ORM dialects, migration tools;

• application runtime: Java/JDK, Python, Go, Node.js, framework versions;

• backup/restore tooling и проверенные процедуры восстановления;

• replication/cutover tooling: physical replicas, logical replication, read replicas, blue/green;

• observability agents и query analytics;

• provider policies: EOL calendars, extended support, supported upgrade paths, regions/features;

• процесс: есть ли ответственный, staging restore, performance baseline, runbook, abort criteria.

Именно поэтому старение базы редко проявляется одним тикетом. Например, MySQL 5.7→8.0 затрагивал не только сервер. В MySQL 8.0 появились global transactional data dictionary, caching_sha2_password как preferred/default authentication plugin, были удалены некоторые deprecated account-management features, а клиенты и connectors без поддержки caching_sha2_password могли столкнуться с compatibility issues (MySQL docs). Поэтому «обновить базу» быстро превращалось в аудит приложений, драйверов, пользователей, миграционных инструментов и CI.

MongoDB показывает похожую проблему другим способом. В Atlas major-version upgrade документация прямо рекомендует создать staging cluster и протестировать приложение перед production upgrade; major versions обновляются только по одной, без skip, а downgrade после major upgrade недоступен, если FCV заранее не был pinned (MongoDB Atlas docs). Это не деталь конкретного managed-сервиса, а нормальная логика stateful-систем: совместимость надо проектировать заранее.

Почему старые базы остаются в production годами

Объяснять это только negligence неправильно. Часто команда не обновляет базу не потому, что ей всё равно, а потому что текущая версия — меньшее зло в краткосрочном горизонте.

1. Upgrade выглядит как инцидент, который команда сама себе создаёт

В stateless-сервисе можно откатить контейнер, вернуть feature flag и пережить bad deploy. С базой так не всегда работает: данные уже изменились, системные таблицы обновлены, replication topology перестроена, новые бинарники могли записать формат, который старая версия не понимает.

Поэтому у малого SaaS возникает рациональный страх: «мы потратим выходные, получим downtime, а продуктовой пользы клиент не увидит». TechRadar в пересказе отчёта Percona как раз подчёркивает эту напряжённость: production database upgrade often becomes a major risky project requiring cross-stack migration, testing, infrastructure and cloud changes (TechRadar).

2. Нет production-like staging

Staging, куда раз в месяц деплоится пустая схема с seed-данными, почти бесполезен для database upgrade. Нужны реальные cardinality, индексы, размеры таблиц, query mix, extensions, параметры, replication lag и storage behavior. Без этого команда проверяет только «приложение стартует», но не проверяет то, что реально ломается под нагрузкой.

3. Backups есть, restore никто не проверял

Наличие nightly backup не означает возможность восстановиться за приемлемое RTO/RPO. AWS Well-Architected Reliability Pillar прямо рекомендует периодически выполнять recovery, чтобы проверить целостность backup и сам процесс восстановления (AWS Well-Architected). Для database upgrades это не абстрактная DR-гигиена, а часть rollback/roll-forward стратегии.

4. Dependency audit слишком дорогой для маленькой команды

У SMB-продукта может не быть DBA или отдельной platform-команды. Один senior backend engineer знает, что где-то есть старый BI connector, legacy cron уже переписан «почти полностью», а staging не поднимает read replica. Пока нет внешнего давления, upgrade проигрывает roadmap-фичам.

Это не делает риск менее реальным. Это значит, что процесс должен быть минимальным и регулярным, а не enterprise-heavy.

Что EOL означает у PostgreSQL, MySQL, MariaDB и MongoDB

EOL не означает, что база остановится в полночь. Обычно это означает: upstream больше не обязан выпускать security fixes, bug fixes и поддерживать версию в стандартном жизненном цикле. Для бизнеса это меняет разговор с «технической рекомендации» на risk acceptance.

Важный нюанс: не нужно обновляться в первый день major release. Для PostgreSQL, например, логично учитывать поддержку extensions, managed-provider availability и первые minor releases. Цель не «быть всегда на latest», а не оказаться внезапно за пределами поддержки без проверенного пути вперёд.

На момент research PostgreSQL 19 был запланирован на сентябрь 2026, но финальный релиз на 18 сентября 2026 не был подтверждён: roadmap говорит planned September 2026, release notes показывали placeholder release date, а wiki open items упоминали Beta 4 на 24 сентября 2026 (roadmap, release notes, open items). Даже как planned release он полезен как пример: новые major versions несут не только риск, но и capability upside — SQL/PGQ property graph queries, REPACK command, improvements to logical replication и autovacuum improvements перечислены в draft/live release notes (PostgreSQL 19 notes).

Почему EOL — это бизнес-риск, а не только patch hygiene

Security и audit

OWASP Top 10 A06 относит software к vulnerable/outdated, если оно vulnerable, unsupported или out of date (OWASP A06). OWASP Infrastructure Security Risks 2024 отдельно описывает outdated software как накопление vulnerability risk из-за отсутствия update management (OWASP ISR01).

Для компаний с payments или enterprise-клиентами это быстро становится compliance-разговором. PCI SSC FAQ по unsupported OS/software говорит, что PCI DSS требует держать системы обновлёнными vendor-supplied security patches; когда unsupported software cannot be patched, нужны compensating controls против vulnerabilities, которые могут привести к exploit unsupported code (PCI SSC FAQ 1130).

То есть EOL-база — это не автоматически failed audit, но это вопрос, на который надо иметь документированный ответ: какие compensating controls, какой migration plan, кто принял риск и до какой даты.

Cost и provider policy

Managed database снижает toil, но не отменяет lifecycle. AWS RDS для MySQL публикует engine release calendars и Extended Support timelines; pricing page указывает, что restore snapshot to MySQL 5.7 после 29 февраля 2024 влечёт RDS Extended Support pricing до upgrade to MySQL 8.0+ или удаления, и read replicas тоже могут попадать под charges, если работают после standard support (RDS MySQL versions, RDS MySQL pricing).

AWS RDS для PostgreSQL публикует таблицы с community release date, RDS release date, community EOL, RDS end of standard support, Extended Support pricing start и end of Extended Support (RDS PostgreSQL calendar). Это хороший образец того, как должен выглядеть внутренний EOL calendar компании.

Google Cloud SQL policy говорит, что instances на community EOL major versions MySQL и PostgreSQL включаются в extended support (Cloud SQL version policies). Azure Database for PostgreSQL flexible server поддерживает major versions до community EOL и отдельно публикует retirement details (Azure PostgreSQL version policy).

Практический вывод: managed-сервис превращает EOL не в невидимую проблему, а в billing/policy event. Иногда это удобно — есть snapshots, automated backups, blue/green. Иногда неприятно — provider-controlled windows, version lag, feature limitations, extended support charges.

Product velocity и hiring

Старая база блокирует не только security fixes. Она ограничивает roadmap: новые query capabilities, replication improvements, tooling, driver versions, ORM features, cloud-provider workflows. Если приложение зависит от старого auth plugin или неподдерживаемого connector, каждое product change начинает проверяться на совместимость с legacy stack.

Есть и организационный риск: чем дольше версия живёт без upgrade practice, тем меньше людей понимают, как её обновлять. Уходит инженер, который помнит параметры, extensions и странный workaround в migration script, — и технический долг становится operational fragility.

Rollback базы данных не похож на rollback приложения

Самая опасная фраза перед database upgrade: «если что — откатимся». Иногда откат возможен. Часто — только через заранее подготовленный restore, cutover назад или roll-forward.

Примеры из документации:

• MySQL 8.0 release notes прямо говорят, что downgrade from MySQL 8.0 to 5.7 или from a MySQL 8.0 release to previous MySQL 8.0 release is not supported (MySQL 8.0 release notes).

• MongoDB Community Edition binary downgrades не поддерживаются; Enterprise downgrade требует support assistance, и MongoDB поддерживает только single-version downgrades (MongoDB downgrade docs).

• MongoDB Atlas major upgrade нельзя откатить после upgrade, если FCV заранее не был pinned (Atlas major version change).

• PostgreSQL pg_upgrade link mode ускоряет upgrade и экономит место, но после запуска нового кластера старый кластер уже нельзя использовать (pg_upgrade docs).

• MariaDB documentation говорит, что mariadb-upgrade нужно запускать после upgrade между major releases для обновления system tables и проверки таблиц; downgrade между major versions имеет ограничения и усложняется после шагов, меняющих system tables (mariadb-upgrade, major upgrades).

Поэтому перед change window нужно выбрать не «откатимся как-нибудь», а конкретную стратегию:

1. Snapshot/backup restore — надёжно, но может не уложиться в RTO и теряет изменения после backup, если нет дополняющего механизма.

2. Logical replication cutover — часто удобнее для минимизации downtime и rollback через старую сторону до точки необратимости, но требует совместимости схемы, careful switchover и контроля lag.

3. Blue/green — managed-вариант, где provider помогает создать green environment и переключиться, но ограничения зависят от engine/version/region.

4. Roll-forward — исправлять проблему на новой версии, используя feature flags, backward-compatible schema и заранее подготовленные remediation scripts.

Для баз данных roll-forward часто честнее, чем обещание мгновенного rollback.

Upgrade paths: что учитывать по основным СУБД

PostgreSQL

PostgreSQL documentation описывает три основных подхода к major upgrade: logical dump/restore, pg_upgrade и logical replication between major versions (Upgrading a PostgreSQL Cluster). File-system-level backups не подходят для dump/restore между major versions, а logical replication может работать между разными major versions.

pg_upgrade часто выбирают ради скорости, но у него есть operational constraints: cluster settings compatibility checks, ограничения по contrib modules, OID-referencing system data types и standby upgrade flows; link mode меняет rollback trade-off (pg_upgrade).

PostgreSQL 19 migration notes добавляют хороший пример того, почему нужен тестовый restore, а не просто пустой staging: для миграции нужны pg_dumpall, pg_upgrade или logical replication; dumps, созданные pre-PostgreSQL 19 pg_dump/pg_dumpall при standard_conforming_strings=off, may not properly load into PostgreSQL 19 and later (PostgreSQL 19 release notes). Это именно тот класс проблемы, который обнаруживается только при rehearsal.

MySQL

Для MySQL upgrade readiness должен начинаться с compatibility check. MySQL Shell содержит Upgrade Checker Utility для проверки MySQL 5.7 или 8.0 instances перед upgrade; Oracle рекомендует запускать readiness checks до перехода на новые releases (Upgrade Checker Utility).

Но checker не заменяет dependency audit. MySQL Connector/J documentation публикует compatibility information across MySQL Server and Java versions и рекомендует latest Connector/J for MySQL Server 8.0 and higher (Connector/J compatibility). Аналогично надо проверять ORM dialects, migration tools, BI/ETL connectors, auth plugins и runtime versions.

MariaDB

MariaDB upgrade нельзя сводить к замене пакетов. После major upgrade documentation требует mariadb-upgrade, чтобы обновить system tables и проверить tables (mariadb-upgrade). Для версий за EOL важно не путать «ещё запускается» с «получает security maintenance»: Foundation policy прямо говорит, что для End-of-Life releases security updates не предоставляются Foundation (MariaDB policy).

MariaDB 10.6 EOL 6 июля 2026 — хороший пример прагматичного переходного состояния: Foundation советовала пользователям на 10.6 использовать latest 10.6 maintenance release while preparing migration, но подчёркивала, что migration should be prepared now (MariaDB 10.6 EOL).

MongoDB

MongoDB major releases имеют five-year lifecycle, а Atlas major upgrades требуют staging cluster, application testing, one-major-at-a-time upgrade и careful FCV handling (MongoDB versioning, Atlas upgrade docs).

FCV особенно важен как control point: если его не pinned до upgrade, downgrade path может исчезнуть. Это не значит, что FCV — rollback strategy сам по себе. Это значит, что compatibility state надо планировать как часть runbook.

Managed DB workflows

Amazon RDS Blue/Green Deployments поддерживает MariaDB, MySQL и PostgreSQL versions и может использоваться для major/minor engine upgrades, parameter changes и schema changes в staging environment; AWS отмечает, что PostgreSQL blue/green может использовать logical или physical replication depending on conditions (RDS Blue/Green).

Это полезный инструмент, но не магия. Всё равно нужны release notes review, dependency audit, performance baseline, replication lag checks, success/abort criteria и понимание provider-specific limitations.

Минимальный viable upgrade program для SaaS/SMB

Для маленькой команды не нужен сразу «database platform maturity model» на 40 страниц. Нужен процесс, который предотвращает сюрпризы.

Практический порядок такой: сначала понять, какие базы у вас есть и когда они выходят из поддержки; затем доказать, что вы можете восстановиться и протестировать upgrade на production-like данных; после этого разбирать зависимости, performance и runbook конкретного окна.

1. Inventory

Соберите таблицу по всем production и critical non-production БД:

• engine и exact version;

• managed/self-managed, provider, region;

• ответственный: команда и конкретный человек;

• business criticality и data sensitivity;

• upstream EOL и provider standard support end;

• extensions/plugins/FCV/auth plugins;

• drivers/ORMs/migration tools;

• backup method, retention, last successful restore test;

• replicas, logical replication, read replicas, analytics consumers;

• observability и alerting coverage.

Главное — не идеальная CMDB, а отсутствие неизвестных production-баз.

2. EOL calendar

Минимальная колонка calendar должна включать:

• current version;

• upstream EOL;

• managed-provider end of standard support;

• extended support start и момент начала дополнительных расходов, если применимо;

• target version;

• dependency audit deadline;

• staging restore rehearsal;

• performance test window;

• production change window;

• risk owner.

AWS RDS PostgreSQL release calendar — хороший пример структуры: там рядом видны community release date, RDS release date, community EOL, RDS end of standard support, Extended Support pricing start и end of Extended Support (AWS RDS PostgreSQL calendar). Такой же формат полезно вести внутри компании, даже если вы self-managed.

После этого у команды появляется не абстрактное «надо когда-нибудь обновиться», а видимый календарь рисков и решений.

3. Dependency audit

Для каждого upgrade проверьте:

• официальные release notes и breaking changes;

• server parameters и deprecated/removed features;

• extensions/plugins compatibility;

• drivers and connectors;

• ORM dialects;

• migration framework;

• app runtime versions;

• BI/ETL jobs и read-only consumers;

• backup/restore tools;

• monitoring agents.

Для MySQL обязательно запускать Upgrade Checker Utility там, где он применим (MySQL Shell Upgrade Checker). Для PostgreSQL — тестировать выбранный путь: dump/restore, pg_upgrade или logical replication. Для MongoDB Atlas — staging cluster и one-major-at-a-time rehearsal.

4. Production-like staging через restore

Staging должен быть построен из свежего backup/snapshot, а не из synthetic seed data. Если данные нужно обезличить, сохраняйте важные свойства workload: объёмы, cardinality, распределения, индексы, constraints, approximate query mix. Иначе performance test будет красивым, но бесполезным.

5. Performance baseline

До upgrade зафиксируйте baseline:

• top queries by time и frequency;

• p95/p99 latency на application-level и DB-level;

• throughput;

• locks/deadlocks;

• replication lag;

• checkpoint/vacuum behavior для PostgreSQL;

• CPU/IO/storage saturation;

• slow queries;

• connection pool saturation;

• ключевые business transactions.

PostgreSQL поставляет pgbench и поддерживает custom benchmark scripts (pgbench docs). Percona Monitoring and Management документируется как open-source monitoring/observability solution для MySQL, PostgreSQL и MongoDB; Query Analytics помогает анализировать, где queries spend time и сравнивать performance characteristics over time (PMM docs, Query Analytics). MongoDB engineering materials также описывают automated performance testing для обнаружения regressions до release (paper, MongoDB engineering blog).

Но generic benchmark недостаточен. База может улучшиться на pgbench, но просесть на ваших ORM-generated queries, data distribution или индексах. Baseline должен включать production-like workload.

6. Runbook и decision log

Runbook должен отвечать на вопросы:

• кто отвечает за решение во время окна;

• какие шаги выполняются и кем;

• какие команды уже протестированы в staging;

• когда начинается freeze на schema/app changes;

• какие health gates считаются success;

• какие metrics являются abort criteria;

• что делаем при replication lag, failed migration, unexpected slow queries;

• какой rollback/restore/roll-forward path выбран;

• когда rollback window считается закрытым;

• какие destructive cleanup steps отложены.

Если этого нет в документе до upgrade window, команда будет проектировать процесс под давлением.

Schema migrations: не смешивайте engine upgrade и rewrite схемы

Часто database upgrade страшен не только из-за версии ядра, а из-за накопленного backlog schema changes. Команда думает: «раз всё равно трогаем базу, давайте заодно перепишем таблицы». Это увеличивает blast radius.

Лучше отделять:

• engine upgrade;

• application compatibility changes;

• schema evolution;

• data backfills;

• destructive cleanup.

Для schema evolution полезен expand/contract pattern. Prisma описывает его как двухшаговый подход: сначала добавить новую форму и скопировать данные, затем удалить старую форму, когда её уже никто не читает (Prisma docs). GitLab documents post-deployment migrations, разделяя application deployment и state-mutating database changes; для удаления column используется no-downtime pattern: сначала deploy code, который больше не зависит от column, потом migration, которая удаляет column (GitLab docs).

Для MySQL large tables GitHub’s gh-ost — пример online schema migration tool, который делает live schema changes low-impact, controllable, auditable и operations-friendly через ghost table pattern без triggers (GitHub Engineering). Это не major-version upgrade tool, но он снижает общий страх перед изменениями базы.

Практическое правило: если можно не совмещать engine upgrade, large schema rewrite и app rewrite — не совмещайте.

Canary, cutover и post-upgrade validation

SRE-подход к релизам применим к базам, но с ограничениями. Google SRE Workbook описывает canarying как gradual, measured change, где canary должен с достаточной уверенностью обнаруживать bad candidates; release engineering работает с SRE над canary, non-interrupting releases и rollback strategies (Canarying Releases, Release Engineering).

Для базы canary сложнее, потому что state общий и mutable. Но gradual exposure всё равно возможен:

• read-only shadow traffic;

• analytics/read-only consumers сначала;

• internal tenants или internal traffic;

• canary tenants, если архитектура multi-tenant это позволяет;

• read replica testing;

• blue/green green environment;

• controlled cutover with lag monitoring.

Health gates должны быть конкретными:

• application error rate;

• p95/p99 latency;

• slow query volume;

• lock waits/deadlocks;

• replication lag;

• connection saturation;

• CPU/IO/storage;

• disk growth;

• backup success;

• business transaction success rate.

После cutover не стоит сразу удалять старую среду, dropping columns, менять FCV без необходимости или чистить fallback path. Дайте системе пройти период повышенного мониторинга.

Managed DB vs self-managed: где долг исчезает, а где переезжает

Выбор не сводится к «managed лучше» или «self-managed гибче». Для founder/CTO полезнее смотреть на оси:

• есть ли in-house DBA/SRE competence;

• насколько workload нестандартный;

• насколько критичны compliance и audit;

• можно ли принять provider timelines;

• насколько важна cost predictability;

• каков RTO/RPO;

• какие extensions/features нужны продукту.

Managed DB может быть отличным решением для SMB, но EOL calendar всё равно нужен. Просто вместо upstream-only lifecycle вы отслеживаете ещё и provider policy.

Практический вывод: цель — не latest, а управляемый выбор

Database upgrade debt опасен не тем, что старая версия обязательно сломается завтра. Он опасен тем, что команда теряет возможность выбирать момент и способ изменения.

Если есть inventory, EOL calendar, dependency audit, staging restore, tested backups, performance baseline и runbook, CTO может принять осознанное решение: подождать minor release, купить extended support на ограниченный период, поставить compensating controls, запланировать migration после peak season или ускорить upgrade из-за audit/product need.

Если этого нет, решение за команду принимают внешние события: CVE, auditor, cyber insurance questionnaire, cloud-provider billing, forced upgrade window или уход единственного инженера, который помнит систему.

Минимальный план на ближайший квартал для SaaS/SMB:

1. Найти все production и critical databases.

2. Зафиксировать версии, ответственных, provider, extensions/plugins, drivers и backup method.

3. Добавить upstream EOL и managed-provider support dates.

4. Проверить, когда последний раз выполнялся restore, а не только backup.

5. Поднять staging из свежего backup/snapshot.

6. Запустить доступные preflight checks и прочитать release notes для target version.

7. Снять performance baseline по реальному workload.

8. Написать runbook с success, abort и rollback/roll-forward strategy.

9. Не совмещать upgrade с крупным schema rewrite без необходимости.

10. Внести database upgrades в тот же planning system, где живут SLO, security remediation и roadmap-enabling platform work.

Хорошая команда не та, которая обновляется первой. Хорошая команда та, которую EOL не застаёт врасплох.