Замена MSSQL на Postgres Pro и Tantor: матрица миграции и реальные кейсы
Гайд для CIO и DBA: переход с Microsoft SQL Server на Postgres Pro / Tantor. Конвертация T-SQL в pgPL, миграция SSIS и SSRS, схема blue-green переключение, сроки 4-12 мес, бюджет.
Microsoft SQL Server в России до 2022 года — стандарт для корпоративных систем средней сложности: 1С на MSSQL, учётные системы, CRM, биллинговые системы среднего бизнеса, портальные решения. После 2022 года поддержка MSSQL для российских компаний прекращена, лицензии не продлеваются, а с 1 января 2025 года использование MSSQL на значимых объектах КИИ запрещено указом Президента №166. К началу 2026 года задача российского CIO — заменить десятки и сотни MSSQL-инстансов на отечественные СУБД. По нашему опыту проектов 2024-2026 годов, в 95% случаев целевая платформа — Postgres Pro Enterprise или Tantor.
Эта статья — для CIO, главного архитектора и DBA, ведущих программу миграции с MSSQL. Внутри: матрица функционального соответствия, разбор сложностей с SSIS/SSRS/SSAS, методология конвертации T-SQL в pgPL, реалистичные сроки и бюджеты, типовые ошибки.
Postgres Pro vs Tantor: выбор целевой СУБД
Оба продукта основаны на PostgreSQL и покрывают паритет с MSSQL для большинства корпоративных сценариев. Реальный выбор сводится к четырём критериям.
Зрелость продукта. Postgres Pro — лидер рынка с подтверждёнными внедрениями в банках, телекоме, госсекторе. Многолетняя история, стабильный roadmap, большая команда разработки. Tantor — активно развивающийся продукт с 2023 года, есть крупные внедрения, особенно в сегменте, использующем Astra Linux.
Экосистема подрядчиков. Для Postgres Pro доступно больше команд с опытом проектов миграции — это критично для программ длительностью год и более, когда нужно резервирование команд. Tantor имеет меньше внешних подрядчиков, но активно растёт.
Платформа управления. Tantor Platform — собственный инструмент управления кластерами Tantor с GUI и автоматизацией задач DBA. Postgres Pro полагается на pgAdmin и сторонние инструменты (Patroni, pgBouncer, pgBackRest). Если нужна готовая платформа с минимальной настройкой — Tantor выигрывает.
Совместимость со стеком ОС. Tantor хорошо вписан в Astra Group (Astra Linux + ALD Pro + Tantor Platform + AstraInfoSec). Postgres Pro универсален, работает на любых российских ОС из реестра Минцифры. Для компаний, стандартизирующихся на Astra-стек, Tantor — естественный выбор.
В типовых проектах 2026 года выбор: Postgres Pro Enterprise для больших гетерогенных ландшафтов с разнообразием подрядчиков; Tantor для проектов с глубокой стандартизацией на Astra-стек или с требованием готовой платформы управления.
Матрица функционального паритета MSSQL → Postgres Pro / Tantor
| Функционал MSSQL | Аналог в Postgres Pro / Tantor | Паритет |
|---|---|---|
| Базовый OLTP (CRUD, ACID, MVCC) | Стандартный PostgreSQL + 64-bit XID | 100% |
| T-SQL | pgPL (расширенный PL/pgSQL) | 70-85% (15-30% переписывается) |
| Identity columns | GENERATED AS IDENTITY или sequence | 100% |
| Hierarchyid | ltree extension | 90% |
| Partitioning | Declarative partitioning | 95% |
| Materialized views (indexed views) | Materialized views | 90% |
| Filtered indexes | Partial indexes | 100% |
| Columnstore indexes | columnar extension (cstore_fdw) | 70-80% (производительность зависит) |
| Full-text search | tsvector + RUM | 95% |
| Service Broker | RabbitMQ / Kafka + pgBouncer | 80% (другая архитектура) |
| AlwaysOn Availability Groups | Streaming replication + Patroni | 85% |
| Linked servers | postgres_fdw, mysql_fdw, oracle_fdw | 85% |
| CLR-сборки (.NET в БД) | pgPL / PL/Python / PL/V8 | 60-75% (переписывание) |
| SSIS (ETL) | Apache NiFi / Pentaho / Hop | 80% (другие инструменты) |
| SSRS (отчётность) | Yandex DataLens / Visiology / FineReport | 80% (пересборка отчётов) |
| SSAS (OLAP-кубы) | Greenplum + DataLens / Visiology | 75% (пересборка кубов) |
| SQL Server Agent (планировщик) | pg_cron / Apache Airflow | 90% |
| Database Mail | postgres_mail extension / внешний SMTP | 90% |
Главные зоны риска — SSIS, SSRS, SSAS. Это отдельные продукты Microsoft, и миграция требует не только смены СУБД, но и переархитектуры ETL, отчётности и аналитического стека. По нашему опыту, 40-60% бюджета миграции с MSSQL уходит именно на эти три компонента, а не на саму БД.
T-SQL → pgPL: что автоматизируется
T-SQL и pgPL — родственные диалекты PL/SQL-семейства, но синтаксис и встроенные функции отличаются.
Инструменты автоматической конвертации:
- sqlserver2pgsql — open-source инструмент, аналог ora2pg для MSSQL. Покрывает базовые конструкции.
- Tantor Migration Toolkit — коммерческий инструмент в составе Tantor Platform.
- AWS Schema Conversion Tool (SCT) — может использоваться offline для оценки.
Покрытие — 60-80% строк. Остальное — ручная работа.
Автоматически конвертируется:
- Процедуры и функции с параметрами
- Циклы WHILE, IF/ELSE, базовые курсоры
- Операторы SELECT, INSERT, UPDATE, DELETE, MERGE
- Обработка исключений TRY … CATCH → EXCEPTION
- Триггеры
- Базовые встроенные функции (LEN, SUBSTRING, REPLACE)
Переписывается руками:
- TOP → LIMIT/OFFSET. Везде, где использовался TOP с подзапросами или с TIES — переписывается с учётом семантики.
- Идентификаторы в квадратных скобках
[]— заменяются на двойные кавычки или без них (если идентификатор не зарезервированное слово). - Типы данных: DATETIME → timestamp, DATETIME2 → timestamp; MONEY → numeric(19,4); UNIQUEIDENTIFIER → uuid; ROWVERSION/TIMESTAMP → версионирование через xmin или собственная колонка.
- Функции T-SQL: GETDATE() → now(); ISNULL → COALESCE; CONVERT с маской → CAST + to_char; DATEPART → EXTRACT; STUFF, FOR XML — пересборка под json_agg, string_agg.
- Идентифицирующие столбцы IDENTITY — переписываются на sequence или GENERATED AS IDENTITY.
- Хранимые процедуры с параметрами OUTPUT — синтаксис другой, переписываются как функции с RETURNS RECORD или с TABLE-output.
- Глобальные временные таблицы (##) — переписываются на схему с обычными таблицами с управлением жизненным циклом.
- Service Broker — целевая система выбирается (RabbitMQ, Kafka), приложение переписывается под новый брокер.
- CLR-сборки — переписываются на pgPL или PL/Python; сложные кейсы — на внешний сервис, вызываемый через REST API.
Реалистичный коэффициент: 60-80% автоматики + 1-2 человеко-месяца ручной работы на 100 тысяч строк T-SQL.
SSIS, SSRS, SSAS: три отдельных проекта внутри миграции
Это три отдельных мини-программы внутри миграции с MSSQL. Игнорировать их на этапе планирования — гарантированный провал бюджета.
SSIS (Integration Services) — ETL. Стандартный сценарий для российской компании со среднего объёма ландшафтом — 50-200 SSIS-пакетов, накопленных за 5-10 лет. Они не конвертируются автоматически — это собственный формат Microsoft. Подходы к замене:
- Apache NiFi — лучший выбор для большинства типовых ETL: визуальный low-code, большой набор коннекторов, активная разработка. Аналог SSIS по парадигме.
- Apache Hop — современный преемник Pentaho Kettle, бесплатный, хорошо работает с PostgreSQL.
- Pentaho Data Integration (бывший Kettle) — стабильная open-source платформа с большим коммьюнити.
- Кастомные ETL на Python (pandas + SQLAlchemy + Airflow для оркестрации) — для сложных нестандартных пайплайнов.
Срок миграции SSIS — 3-6 месяцев параллельно основной миграции БД для портфеля 50-100 пакетов.
SSRS (Reporting Services) — отчётность. SSRS-отчёты строятся на RDL-формате (XML) и не конвертируются в другие платформы. Подходы к пересборке:
- Yandex DataLens — облачная BI, хорошо подходит для интерактивных дашбордов и аналитической отчётности.
- Visiology — продвинутая BI с OLAP-движком, подходит для финансовой отчётности.
- FineReport — продукт для пиксельной отчётности (печатные формы, шаблоны для регулятора), реалистичный аналог SSRS для документной отчётности.
- Luxms BI — российский BI с фокусом на корпоративные внедрения.
Типичный портфель — 100-500 SSRS-отчётов. Пересборка занимает 4-8 месяцев и требует отдельной команды BI-разработчиков. Преимущество — повод пересмотреть актуальность отчётов: обычно 30-50% из них уже не используются.
SSAS (Analysis Services) — OLAP-кубы. Самая сложная часть миграции. SSAS-кубы (как многомерные, так и табличные) реализуются на собственном движке Microsoft. Подходы:
- Greenplum (Arenadata DB) — массивно-параллельная аналитическая СУБД, целевая платформа для пересборки кубов с подключением BI поверх.
- Postgres Pro Enterprise + columnar extensions — для кубов среднего объёма.
- Visiology — встроенный OLAP-движок, можно делать многомерные модели «в инструменте».
Стандартный срок — 6-12 месяцев параллельно. Большие проекты SSAS — отдельная программа за 12-18 месяцев.
Сроки и бюджет миграции с MSSQL
Реалистичные диапазоны для российских компаний на 2026 год.
| Размер ландшафта | Срок | Бюджет |
|---|---|---|
| До 500 ГБ, 5-10 клиентов, базовый T-SQL, без SSIS/SSRS | 4-6 мес | 5-12 млн ₽ |
| 500 ГБ - 5 ТБ, 10-30 клиентов, портфель SSIS, средний SSRS | 6-10 мес | 12-25 млн ₽ |
| 5+ ТБ, тяжёлый SSIS, SSRS, есть SSAS-кубы | 10-14 мес | 25-50 млн ₽ |
Структура бюджета:
- Лицензии Postgres Pro Enterprise или Tantor — 20-30%
- Миграция схемы и T-SQL — 25-35%
- Миграция SSIS-портфеля — 15-25%
- Пересборка SSRS-отчётов — 10-20%
- Пересборка SSAS-кубов (если есть) — дополнительно 20-40% от базового бюджета
- Адаптация приложений-клиентов — 10-15%
- Сопровождение и обучение DBA — 5-10%
Blue-green переключение для MSSQL
Стандартный сценарий для критичных систем — миграция с двойная запись через CDC. Инструменты CDC для MSSQL: Debezium с MSSQL-коннектором, штатный CDC SQL Server (если включён), кастомные триггерные решения для небольших объёмов.
Этапы:
- Подготовка целевой Postgres Pro / Tantor с скомпилированной схемой и сконвертированным T-SQL (3-6 недель)
- Массовая загрузка данных через bcp + COPY (12-48 часов параллельной загрузки)
- Запуск CDC и догон отставания (1-3 дня)
- двойная запись через приложение или через CDC; постепенный перевод чтения (2-6 недель)
- Сверка данных по checksum + sample audit (параллельно)
- переключение (1 неделя)
- SLA-сопровождение (3-6 месяцев)
Типовые ошибки в миграциях с MSSQL
Ошибка 1: Недооценка SSIS-портфеля. В план включают только миграцию БД, а SSIS — «потом разберёмся». Реальный объём — 15-25% бюджета программы. Без аудита SSIS-портфеля план миграции некорректен.
Ошибка 2: «Пересоберём все SSRS-отчёты один в один». Попытка зеркально воспроизвести 500 SSRS-отчётов в новой BI. Это удваивает бюджет и теряет преимущество BI-инструментов. Правильный подход — пересмотр актуальности (30-50% не используются), классификация на «пиксельные печатные формы» (FineReport) и «интерактивные дашборды» (DataLens, Visiology).
Ошибка 3: Игнорирование Service Broker и CLR-сборок. Если в MSSQL активно используются Service Broker для очередей или CLR для специфической логики — это отдельные миграционные подпроекты с переархитектурой приложений. План должен это учитывать.
Ошибка 4: Поздний proof-of-concept по производительности. Бенчмарк производительности на pre-prod откладывается до конца миграции. На переключение обнаруживается, что нагрузка не выдерживается. Стандарт — PoC с реальным запросным профилем в первые 4-6 недель программы.
Ошибка 5: Отсутствие плана адаптации приложений-клиентов. Приложения, написанные с расчётом на MSSQL (ADO.NET, ORM с T-SQL-специфичными конструкциями), требуют доработки. План должен включать оценку и сроки для каждого приложения-клиента.
Смежные пути миграции — см. миграция с Oracle на Postgres Pro, замена Active Directory, реестр Минцифры 2026, план импортозамещения 2026-2028.
FAQ о замена MSSQL
На что менять MSSQL: Postgres Pro или Tantor?
Оба продукта основаны на PostgreSQL и покрывают функциональный паритет с MSSQL для большинства корпоративных сценариев. Постgres Pro — лидер рынка с большой экосистемой подрядчиков и подтверждёнными внедрениями в банках, телекоме и госсекторе. Tantor — активно развивающийся продукт с собственной платформой управления кластерами и хорошим инструментарием DBA. Выбор обычно сводится к: 1) Наличию подрядчика с опытом — для Postgres Pro доступно больше команд. 2) Требованиям к платформе управления — Tantor Platform полнее, чем стандартный pgAdmin. 3) Совместимости со стеком ОС — Tantor хорошо вписан в Astra Linux + ALD Pro. 4) Стоимости лицензии. В большинстве проектов на 2026 год выбор Postgres Pro Enterprise, для проектов с Astra-стеком — Tantor становится сильным вариантом.
Какие функции MSSQL не имеют прямого аналога в PostgreSQL?
Главные пробелы: 1) SQL Server Reporting Services (SSRS) — отчётность; заменяется на Yandex DataLens, Visiology, FineReport или встроенные средства Postgres Pro + pgBadger. 2) SQL Server Integration Services (SSIS) — ETL; заменяется на Pentaho, Apache NiFi, Hop, либо переписывается на Python/Java. 3) SQL Server Analysis Services (SSAS) — OLAP; заменяется на Greenplum + DataLens или Visiology. 4) AlwaysOn Availability Groups — заменяется на streaming replication + Patroni + балансировщик. 5) Linked Servers — заменяется на foreign data wrappers (postgres_fdw, mysql_fdw) или ETL. 6) Service Broker — заменяется на PgBouncer, RabbitMQ, Kafka. 7) CLR-сборки (.NET в БД) — переписываются на pgPL или PL/Python. По каждой из этих позиций есть рабочее решение, но миграция требует переархитектуры приложения.
Как конвертируется T-SQL в pgPL?
T-SQL и pgPL — родственные диалекты, но не идентичные. Конвертация работает на двух уровнях: автоматический инструмент (sqlserver2pgsql, AWS Schema Conversion Tool, Tantor migration tools) покрывает 60-80% строк, остальное — ручная адаптация. Автоматически конвертируется: процедуры, функции, циклы, обработка исключений, базовые операторы SQL, триггеры. Переписывается руками: 1) Конструкции с TOP — заменяются на LIMIT/OFFSET. 2) Идентификаторы в квадратных скобках — кавычки или без них. 3) Типы DATETIME, DATETIME2, MONEY — конвертируются в timestamp, numeric. 4) Функции T-SQL (GETDATE, ISNULL, CONVERT, DATEPART) — заменяются на now(), COALESCE, CAST, EXTRACT. 5) Динамический SQL с sp_executesql — EXECUTE в pgPL. 6) Глобальные временные таблицы — заменяются на схему с обычными таблицами. 7) IDENTITY — sequence или GENERATED AS IDENTITY. Реалистичный коэффициент: 60-80% автоматики, остальное руками.
Что делать с SSIS-пакетами?
SSIS-пакеты не конвертируются автоматически — это собственный формат Microsoft с визуальной моделью потоков данных. Реалистичные варианты замены на 2026 год: 1) Apache NiFi — визуальный low-code инструмент с большим набором коннекторов, подходит для большинства ETL-задач. 2) Pentaho Data Integration (бывший Kettle) — стабильная open-source платформа с десятилетним опытом. 3) Apache Hop — современный преемник Pentaho, активно развивается. 4) Кастомные ETL на Python с библиотеками pandas, SQLAlchemy, Airflow для оркестрации. 5) Apache Airflow — для сложных оркестрационных сценариев. Стандартный подход: на этапе предпроектного обследования анализируется существующая SSIS-портфельная — типовые задачи (10-20%) переписываются за пару человеко-недель, сложные многоступенчатые пайплайны (5-10%) — отдельный проект, рутинные ETL (70-80%) — пересобираются в NiFi или Hop. Срок миграции SSIS — параллельно основной миграции БД, 3-6 месяцев для портфеля из 50-100 пакетов.
Сколько занимает миграция с MSSQL?
Миграция с MSSQL быстрее, чем с Oracle, потому что объём кастомного PL-кода обычно меньше. Реалистичные сроки на 2026 год: небольшая БД (до 500 ГБ, 5-10 клиентов, типовая структура) — 4-6 месяцев. Средняя БД (500 ГБ - 5 ТБ, 10-30 клиентов, есть SSIS и SSRS) — 6-10 месяцев. Большая БД (5+ ТБ, сложная отчётность, SSAS-кубы) — 10-14 месяцев. Этапы: аудит и proof-of-concept (3-4 недели), миграция схемы и T-SQL (2-4 месяца), миграция данных и двойная запись (1-3 месяца), параллельное использование и сверка (1-2 месяца), переключение и сопровождение (1-2 месяца).
Сколько стоит миграция с MSSQL?
Реальные диапазоны на 2026 год: небольшая БД с базовой функциональностью — 5-12 млн рублей. Средняя БД со среднего объёма T-SQL и SSIS-портфелем — 12-25 млн рублей. Большая БД с тяжёлой отчётностью SSRS и кубами SSAS — 25-50 млн рублей. Структура бюджета: лицензии Postgres Pro Enterprise или Tantor — 20-30%; миграция схемы и T-SQL — 25-35%; миграция SSIS и ETL — 15-25%; адаптация приложений-клиентов — 10-15%; пересборка SSRS-отчётов и SSAS-кубов — 15-25%; сопровождение и обучение — 5-10%.
Что с производительностью на типовых нагрузках MSSQL?
На типовых корпоративных нагрузках (TPS до 3000, базы до 5 ТБ) Postgres Pro Enterprise и Tantor показывают сопоставимую с MSSQL Standard Edition производительность — разница в пределах ±10%. Для большинства бизнес-приложений (учётные системы, CRM, биллинг средней сложности, портальные системы) переход не ощущается пользователями. Заметные расхождения возникают: 1) В тяжёлых OLAP-нагрузках с интенсивным использованием columnstore-индексов MSSQL — нужны другие подходы (columnar extensions, Greenplum). 2) В сценариях с массивным использованием SSRS — нужна переархитектура отчётности. 3) В системах с интенсивным использованием Service Broker — нужна переход на брокер сообщений. Бенчмаркинг на pre-prod с реальным запросным профилем — стандартная часть этапа предпроектного обследования.