IONOS DBaaS: миграции API и дедлайны версий в августе–октябре 2026

В августе 2026 года IONOS Cloud переводил несколько DBaaS-продуктов на инфраструктуру/API v2. Проверка актуальных статусов: 7 сентября 2026 года. 22 сентября выборочно добавлены два объявления от 21 сентября об октябрьском прекращении создания кластеров старых версий; остальная история не переаттестована.

Дополнение 29 сентября: официальная карточка отключения PostgreSQL API v1 содержит Completed 28 сентября в 16:00 UTC / 19:00 МСК. Это подтверждённое завершение мероприятия, а не вывод по истечению запланированного окна. Автоматическая миграция кластеров не обновляет API-клиенты, Terraform и SDK пользователя.

Ближайшие оставшиеся даты в этом календаре — 12 октября для создания новых MariaDB 10.6 и 19 октября для новых PostgreSQL 14. Эти ограничения не означают отключение существующих баз. Августовские события и цены этим дополнением повторно не проверялись.

Короткий календарь

Дата	Сервис	Что происходит
4 августа	In-Memory DB	запрещено создание новых v1 clusters
14 августа	PostgreSQL	первоначальный дедлайн перехода programmatic management с BASIC на TOKEN auth перед миграцией
17–31 августа	PostgreSQL	автоматическая infrastructure migration; провайдер отметил завершение 31 августа в 17:00 UTC
17 августа	MariaDB	запрещено создание новых v1 clusters
24–28 августа	MariaDB	автоматическая migration existing clusters на API v2; окно завершено
31 августа	MariaDB	API v1 EOL; мероприятие закрыто в status-панели
31 августа	In-Memory DB	v1 отключается по объявленному плану; требовалась manual migration, мероприятие закрыто в status-панели
1 сентября	In-Memory DB	действуют новые цены snapshot-возможностей v2
28 сентября, 14:00–16:00 UTC	PostgreSQL	отключение management API v1: In progress в 14:00, Completed в 16:00 UTC; клиентам нужны региональный API v2 и TOKEN auth
12 октября, 16:00–18:00 UTC	MariaDB 10.6	прекращается создание новых кластеров этой версии; не отключение существующих
19 октября, 16:00–18:00 UTC	PostgreSQL 14	прекращается создание новых кластеров этой версии; не отключение существующих

Перед выполнением действий проверяйте status page и актуальную product documentation: IONOS может уточнять окна и инструкции. Статус завершения работ провайдера не доказывает успешную миграцию конкретного клиентского приложения.

Октябрь: ограничения версий СУБД, не API v1

Оба уведомления опубликованы 21 сентября 2026 года в 08:26 UTC и прочитаны 22 сентября на общей официальной панели. Постоянные ссылки: MariaDB 10.6 и PostgreSQL 14; отдельные карточки не загрузились.

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

До начала нужного окна обновите версию в шаблонах создания кластеров и проверьте новый тестовый deployment. Не запускайте major upgrade рабочей БД как побочный эффект замены версии в Terraform: сначала изучите план, совместимость SQL и восстановление. API v1/v2 и MariaDB 10.6/PostgreSQL 14 — разные оси версий; переход management API в сентябре не обновляет движок БД автоматически. Результаты собственных deployment и restore-тестов здесь не заявляются.

PostgreSQL: автоматическая инфраструктурная миграция

IONOS выполнял перенос DBaaS PostgreSQL с v1 infrastructure на v2 с 17 по 31 августа 2026 года. Окно миграции отмечено завершённым 31 августа в 17:00 UTC.

Что делает IONOS автоматически

По объявлению миграции:

• cluster migration выполняется провайдером;
• connection endpoint остается прежним;
• для отдельного cluster ожидалось короткое окно недоступности, обычно несколько секунд;
• весь DBaaS service одновременно не выключается.

Это означает, что application должен нормально переживать кратковременный disconnect/reconnect.

28 сентября — окончательное отключение PostgreSQL API v1

Официальная карточка, повторно прочитанная 29 сентября, подтверждает завершение работ:

Этап	Время
Запланированное окно	28 сентября 2026, 14:00–16:00 UTC / 17:00–19:00 МСК
In progress	28 сентября, 14:00 UTC
Completed	28 сентября, 16:00 UTC

Старый API выведен из эксплуатации; рассчитывать на обращения к v1 нельзя. Два часа между сообщениями — окно работ, не измеренный двухчасовой простой баз. Точное время отклонения первого запроса v1 внутри окна не опубликовано.

Это выключение API управления, а не PostgreSQL-протокола приложения. В анонсе провайдер заявлял отсутствие простоя уже перенесённых баз; собственных SQL-измерений здесь нет. Рабочий SQL-запрос не проверяет возможность создать кластер или управлять им через CI/CD.

Что проверить после отключения:

1. Найдите обращения к v1 в репозиториях инфраструктуры, cron, CI variables и внутренних панелях. Сохраняйте только имена файлов и настройки endpoint, не содержимое credentials.
2. Выберите региональный v2 endpoint из официальной документации своего региона; не конструируйте его заменой строки v1 на v2.
3. Обновите SDK и Terraform provider/modules, затем проверьте read-only запрос к API и terraform plan без применения изменений.
4. Убедитесь, что план не пересоздаёт существующую БД. Протестируйте создание и удаление только отдельного временного кластера.
5. Проверьте ошибки management API в CI/CD и назначьте ответственного за оставшиеся зависимости v1. Не пытайтесь исправить отказ API сменой SQL-пароля приложения.

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

TOKEN authentication для management API

PostgreSQL v2 не поддерживает BASIC authentication для cluster management.

Если PostgreSQL управляется через:

• API scripts;
• SDK;
• Terraform;
• другие IaC tools;

нужно использовать TOKEN authentication. Это не требование заменить SQL-пользователя и пароль приложения токеном Cloud API.

Проверить automation:

CI/CD
  ↓
Terraform / API / SDK
  ↓
IONOS authentication
  ↓
региональный PostgreSQL API v2

Если внутри pipeline все еще hardcoded BASIC credentials, migration data plane может пройти успешно, но management automation перестанет работать. Токен храните в secret manager, исключите его из debug-логов и подготовьте процедуру ротации.

SSD Premium становится обязательным

В PostgreSQL v2 используется только SSD Premium storage.

Кластеры, которые были на:

• HDD;
• SSD Standard;

автоматически переводятся на SSD Premium и после migration тарифицируются по standard SSD Premium rate.

Это нужно считать не только техническим upgrade, но и изменением стоимости.

Сравните сохранённый baseline до миграции с текущим состоянием:

cluster
storage class
allocated GB
monthly storage cost
backup cost
observability cost

После migration сравните invoice/detailing.

Observability

IONOS предлагает optional integration с Logging/Monitoring.

Она тарифицируется отдельно при использовании, поэтому не стоит включать ее автоматически во всех environments без оценки:

• объема metrics/logs;
• retention;
• cardinality;
• стоимости.

MariaDB: automatic cluster migration, manual API migration

Для MariaDB нужно разделять две вещи:

1. migration самого database cluster;
2. migration клиента/automation с API v1 на API v2.

17 августа: v1 provisioning закрыт

После 17 августа новые MariaDB v1 clusters создавать нельзя.

Старый CI pipeline вроде:

terraform apply
  ↓
MariaDB API v1 create cluster

будет получать отказ даже до окончательного EOL API.

24–28 августа: existing clusters мигрировались автоматически

Для planned migration IONOS заявлял:

• zero downtime для database workload;
• сохранение connection strings;
• отсутствие необходимости ручного переноса cluster.

При этом API clients нужно обновить отдельно. В status-панели окно отмечено завершённым.

31 августа: API v1 End of Life

Дедлайн уже прошёл. Должны быть обновлены:

• custom API scripts;
• Terraform configurations/providers;
• SDK integrations;
• internal platform tooling.

Первый аудит ссылок без вывода строк с возможными секретами:

grep -RlniE 'mariadb.*v1|api.*v1|ionos' . \
  --exclude-dir=.git \
  --exclude-dir=vendor \
  --exclude-dir=node_modules

Команда показывает только имена файлов и не гарантирует обнаружение всех references.

MariaDB versions

Прежняя проверка августовского объявления рекомендовала переход с MariaDB 10.6 на поддерживаемую версию. Более новое уведомление от 21 сентября уточняет эксплуатационные условия: ограничение 12 октября касается нового создания, существующие 10.6 не выключаются принудительно. Подробности приведены в октябрьском разделе выше; это не продление поддержки API v1.

Перед major DB upgrade отдельно проверьте:

• SQL modes;
• collation;
• reserved keywords;
• replication;
• ORM compatibility;
• query plans;
• backup restore.

Не объединяйте API migration и database-engine major upgrade в один production change без необходимости.

In-Memory DB: дедлайн уже прошёл

IONOS In-Memory DB v1 отличается от PostgreSQL/MariaDB тем, что automatic migration невозможна.

Клиент должен вручную создать v2 instance, перенести данные и обновить application endpoint.

31 августа — отключение v1

IONOS указывал, что оставшиеся v1 instances будут permanently switched off. Мероприятие отмечено завершённым 31 августа; рассчитывать на работоспособность старого endpoint нельзя.

Если миграция пропущена, сначала уточните у поддержки возможность получения оставшихся данных и восстанавливайте их только из подтверждённого источника. Наличие доступного backup не следует предполагать автоматически.

v2 основан на Valkey

Новая платформа использует Valkey.

IONOS указывает совместимость со стандартными Redis clients, поэтому application code часто не требует существенной переделки.

Но необходимо тестировать:

• protocol compatibility;
• authentication;
• TLS;
• endpoint/port;
• persistence model;
• eviction policy;
• TTL;
• scripts/Lua;
• client-specific options.

Migration flow

подтверждённый источник данных / backup
      ↓
create v2 Valkey instance
      ↓
copy data if persistence required
      ↓
verify counts / keys / TTL
      ↓
change application endpoint
      ↓
observe errors/latency
      ↓
remove remaining v1 dependencies

Исторический план предусматривал переключение до 31 августа. После EOL нельзя обещать rollback на выключенный v1 instance.

Не все Redis-like данные нужно переносить

Если instance используется только как disposable cache, migration может означать создание пустого v2 и постепенный warm-up.

Если там находятся:

• sessions;
• queues;
• locks;
• rate-limit state;
• durable application data;

нужно отдельно определить migration strategy.

Особенно опасно считать queue/cache одинаково disposable.

Snapshot pricing

Для In-Memory DB v2 новые snapshot features получают standard pricing с 1 сентября 2026 года.

Перед включением long retention посчитайте:

number of snapshots
× snapshot size
× retention
× price

и сравните с реальной ценностью restore point.

Что проверить в Terraform

Ищите:

v1 resource types
v1 endpoints
BASIC credentials
old providers/modules
old generated SDK clients

В отдельной рабочей ветке, после сохранения lockfile и защищённой копии state:

terraform init -upgrade
terraform validate
terraform plan

Не применяйте terraform apply только потому, что plan выглядит коротким: внимательно проверьте, не предлагает ли provider recreate database resource вместо in-place adoption. State и вывод plan могут содержать секреты — не публикуйте их в PR и общедоступных логах.

Что проверить в CI/CD

Checklist:

[ ] regional API v2 URL configured
[ ] token auth configured
[ ] secrets stored in secret manager
[ ] old BASIC credentials removed from management integrations
[ ] Terraform/provider updated
[ ] SDK version updated
[ ] read-only smoke test uses v2
[ ] test-cluster lifecycle verified
[ ] rollback does not depend on disabled v1

Application resilience во время migration

Даже для «zero downtime» migration application должен уметь пережить краткий network/database hiccup.

PostgreSQL/MariaDB

Проверьте:

• connection pool;
• reconnect;
• transaction retry policy;
• timeout;
• healthcheck;
• circuit breaker, если используется.

Не делайте автоматический retry всех transactions без проверки idempotency.

In-Memory DB

Проверьте поведение при:

• temporary connection failure;
• DNS/endpoint switch;
• empty cache;
• partial migrated data;
• old/new cluster race в период переключения.

Backup до migration

Managed migration не отменяет независимый backup.

Для критичных databases желательно иметь:

provider backup
+
logical export / tested recovery path
+
backup outside same failure domain

В зависимости от DB size и RPO/RTO стратегия будет разной.

Мониторинг

Перед и после migration сравните:

• connection errors;
• query latency;
• connection count;
• storage latency;
• CPU;
• memory;
• backup status;
• failed Terraform/API operations;
• application 5xx.

Зафиксируйте baseline до окна, иначе после migration трудно доказать regression.

Стоимость

PostgreSQL migration может увеличить storage cost из-за перехода HDD/SSD Standard → SSD Premium.

In-Memory DB меняет snapshot pricing с 1 сентября.

Optional Observability также может иметь отдельную стоимость.

Поэтому migration checklist должен содержать не только техническое «работает», но и:

invoice forecast
usage details
storage class
observability usage
snapshot retention

Отдельно: IP Reservation incident 21–23 августа

Невозможность резервировать и управлять IP blocks через DCD/API была отдельным control-plane incident, а не частью DBaaS migration. Он закрыт 23 августа в 17:49 UTC; актуальная хронология находится в журнале IONOS Cloud.

Приоритет действий после 28 сентября

P0 — оставшиеся зависимости In-Memory DB и MariaDB v1

Августовские дедлайны прошли. Обновить endpoint/API/Terraform/SDK и проверить необходимые данные, sessions, queues и locks.

P0 — оставшиеся зависимости PostgreSQL management API v1

Отключение завершено 28 сентября. Проверить региональный API v2 и TOKEN authentication, убрать зависимости от v1 и проверить management automation отдельно от SQL. Completed у провайдера не означает успешную проверку клиентских CI/CD-задач.

P1 — Billing

Сравнить storage/snapshot/observability charges после миграций.

P2 — cleanup

После успешной migration удалить:

• старые credentials;
• dead code v1;
• legacy endpoints;
• obsolete Terraform modules;
• временные migration flags.

Итоговый checklist

PostgreSQL
[ ] региональный API v2; нет зависимости от отключённого API v1
[ ] TOKEN auth для management API
[ ] v2 management works
[ ] cluster reconnected
[ ] SSD Premium cost checked
[ ] backup checked
[ ] новые deployments после 19 октября не требуют PostgreSQL 14

MariaDB
[ ] no v1 provisioning or management dependencies
[ ] cluster migration verified
[ ] API v2
[ ] Terraform v2
[ ] SDK v2
[ ] DB version reviewed
[ ] новые deployments после 12 октября не требуют MariaDB 10.6

In-Memory DB
[ ] v2 instance created
[ ] data migration strategy chosen
[ ] data transferred if needed
[ ] endpoint changed
[ ] application verified
[ ] no dependency on decommissioned v1
[ ] snapshot pricing reviewed

Источники

• IONOS Cloud Status: миграции и новые уведомления о версиях от 21 сентября
• MariaDB 10.6: ссылка на объявление, текст прочитан на общей панели
• PostgreSQL 14: ссылка на объявление, текст прочитан на общей панели
• PostgreSQL API v1: отключение завершено 28 сентября в 16:00 UTC
• IONOS Token Manager
• IONOS DBaaS documentation
• IONOS In-Memory DB migration documentation