PostgreSQL vs MySQL в 2026: какую реляционную базу данных выбрать

Реляционные базы данных остаются фундаментом подавляющего большинства серверных приложений, и выбор между PostgreSQL и MySQL — одно из первых архитектурных решений при старте нового проекта. По данным Stack Overflow Developer Survey 2025, PostgreSQL третий год подряд занимает первое место среди всех баз данных: 55,6% профессиональных разработчиков используют Postgres, тогда как MySQL — 40,5%. При этом в рейтинге DB-Engines MySQL удерживает вторую строчку (после Oracle), а PostgreSQL — четвёртую, но демонстрирует самый быстрый рост среди всех СУБД.

Эта статья — детальное техническое сравнение PostgreSQL 18 и MySQL 9.x (Innovation) / 8.4 (LTS) по ключевым критериям: архитектура, производительность, расширяемость, работа с JSON, репликация, экосистема и лицензирование. Мы приведём бенчмарки, примеры SQL-кода и конкретные рекомендации, для каких задач подходит каждая СУБД. Статья адресована бэкенд-разработчикам, DBA-инженерам и архитекторам, которые выбирают базу данных для нового проекта или оценивают целесообразность миграции.

Краткий обзор: PostgreSQL в 2026

PostgreSQL — объектно-реляционная СУБД с открытым исходным кодом, разрабатываемая глобальным сообществом с 1996 года (корни проекта уходят в 1986 год, к проекту POSTGRES в Калифорнийском университете Беркли). Текущая мажорная версия — PostgreSQL 18, выпущенная 25 сентября 2025 года. Параллельно поддерживаются версии 17.x, 16.x, 15.x и 14.x.

Ключевые особенности PostgreSQL:

• Расширяемость — пользовательские типы данных, операторы, индексные методы, языки процедур (PL/pgSQL, PL/Python, PL/Perl, PL/V8). Расширения вроде PostGIS, TimescaleDB, pgvector превращают Postgres в геоинформационную, временную или векторную базу данных.
• Стандарты SQL — наиболее полная реализация стандарта SQL:2023 среди всех open-source СУБД. Поддержка оконных функций, CTE, LATERAL JOIN, MERGE с RETURNING, JSON_TABLE.
• Надёжность — MVCC (многоверсионное управление параллельным доступом), WAL (write-ahead logging), PITR (point-in-time recovery), синхронная и асинхронная репликация.
• Новое в PostgreSQL 18 — асинхронная подсистема ввода-вывода (AIO) с ускорением до 3x для последовательных сканирований, функция uuidv7() для генерации UUID с временной меткой, виртуальные генерируемые столбцы, темпоральные ограничения (temporal constraints) для PRIMARY KEY и FOREIGN KEY, поддержка OAuth-аутентификации.

На GitHub зеркало PostgreSQL (postgres/postgres) набрало более 17 000 звёзд. Основная разработка ведётся через собственные мейлинг-листы и систему коммитов. В декабре 2025 года PostgreSQL Contributors Team признала 12 новых значимых контрибьюторов.

Краткий обзор: MySQL в 2026

MySQL — реляционная СУБД, созданная в 1995 году шведской компанией MySQL AB. С 2010 года принадлежит Oracle Corporation. В 2023 году Oracle перевела MySQL на новую модель релизов: LTS-версии (Long-Term Support) с поддержкой 8 лет и Innovation-версии с трёхмесячным циклом. Текущая LTS-версия — MySQL 8.4, актуальная Innovation-версия — MySQL 9.5 (октябрь 2025).

Ключевые особенности MySQL:

• Скорость чтения — InnoDB, движок по умолчанию с MySQL 5.5, оптимизирован под read-heavy нагрузки. Adaptive Hash Index, Buffer Pool и эффективное кеширование делают простые SELECT-запросы быстрыми «из коробки».
• Простота — низкий порог входа, обширная документация, огромная база знаний (WordPress, Drupal, Laravel, Rails — все исторически работают на MySQL).
• Репликация — встроенная async-, semi-sync и Group Replication (InnoDB Cluster) для высокой доступности. MySQL Router для балансировки.
• Новое в MySQL 9.x — тип данных VECTOR для ML/AI-задач, JavaScript-хранимые процедуры через Multilingual Engine (MLE), WebAuthn-аутентификация, улучшенный Event Scheduler, поддержка ENUM/SET в JavaScript-функциях.

MySQL на GitHub (mysql/mysql-server) имеет более 10 500 звёзд. Docker-образ MySQL остаётся одним из самых скачиваемых на Docker Hub — более 1 миллиарда загрузок.

Архитектура и модель расширяемости

PostgreSQL: процессная модель и расширения

PostgreSQL использует процессную модель: каждое клиентское подключение обслуживается отдельным процессом (postgres), форкнутым от основного процесса postmaster. Это обеспечивает изоляцию: падение одного процесса не убивает другие соединения. Однако на системах с тысячами одновременных подключений потребление памяти выше, чем у потоковой модели, — поэтому перед Postgres обычно ставят пулер соединений (PgBouncer, Odyssey, pgcat).

Расширяемость PostgreSQL — его главное архитектурное преимущество. Система каталогов полностью открыта: можно добавлять собственные типы данных, операторы, индексные методы (GiST, GIN, BRIN, SP-GiST), языки хранимых процедур, хуки для планировщика запросов. Расширения загружаются в адресное пространство сервера без перекомпиляции:

-- Установка расширения для полнотекстового поиска на русском языке
CREATE EXTENSION pg_trgm;

-- Установка расширения для работы с векторами (AI/ML)
CREATE EXTENSION vector;

-- Создание таблицы с вектором
CREATE TABLE items (
    id BIGINT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    embedding vector(1536),
    content TEXT
);

-- Поиск ближайших соседей
SELECT id, content
FROM items
ORDER BY embedding <-> '[0.1, 0.2, ...]'::vector
LIMIT 10;

MySQL: потоковая модель и подключаемые движки

MySQL использует потоковую модель: каждое подключение обслуживается потоком внутри одного процесса mysqld. Это экономит память при большом количестве соединений, но усложняет изоляцию ошибок. MySQL поддерживает подключаемые storage engines — но на практике в 2026 году используется почти исключительно InnoDB.

Расширяемость MySQL значительно ограниченнее: нельзя добавить новый тип индекса или тип данных через плагин. В Innovation-релизах 9.x появилась возможность писать хранимые процедуры на JavaScript (MLE), но это Enterprise-фича, недоступная в Community Edition:

-- MySQL: JavaScript хранимая процедура (только Enterprise)
CREATE FUNCTION calculate_tax(price DECIMAL(10,2), rate DECIMAL(5,2))
RETURNS DECIMAL(10,2)
LANGUAGE JAVASCRIPT AS $$
  return price * rate / 100;
$$;

-- MySQL Community: традиционная процедура
DELIMITER //
CREATE FUNCTION calculate_tax(price DECIMAL(10,2), rate DECIMAL(5,2))
RETURNS DECIMAL(10,2)
DETERMINISTIC
BEGIN
    RETURN price * rate / 100;
END //
DELIMITER ;

Производительность: бенчмарки и реальные нагрузки

Вопрос «что быстрее» не имеет универсального ответа — всё зависит от типа нагрузки. Рассмотрим результаты недавних бенчмарков.

Результаты бенчмарков (2025)

По данным независимого исследования MySQL vs PostgreSQL Performance (binaryigor.com) на идентичном оборудовании:

Метрика	PostgreSQL	MySQL	Комментарий
SELECT (простой, по PK)	~9 600 QPS, 2.2 ms	~4 400 QPS, 26.8 ms	PostgreSQL значительно быстрее
INSERT (одиночный)	4.1 ms (mean)	26.5 ms (mean)	PostgreSQL в 6 раз быстрее
INSERT (99th percentile)	6.9 ms	45.8 ms	PostgreSQL стабильнее
Аналитический запрос (JOIN + агрегация)	120 ms	450 ms	PostgreSQL в 3-4 раза быстрее
Bulk COPY/LOAD	2x быстрее (PG 17+)	Базовый LOAD DATA	PostgreSQL оптимизирован
Простой SELECT без индекса, мало данных	Сопоставимо	Сопоставимо	Разница минимальна

Следует оговориться: результаты бенчмарков сильно зависят от настроек (shared_buffers, innodb_buffer_pool_size), схемы данных, версий ПО и железа. В реальных проектах разница может быть как больше, так и меньше.

Когда MySQL быстрее

MySQL исторически хорошо себя показывает на workload-паттернах с преобладанием простых чтений (key-value lookups, SELECT по первичному ключу). InnoDB Buffer Pool эффективно кеширует горячие страницы, а Adaptive Hash Index ускоряет повторяющиеся запросы.

Когда PostgreSQL быстрее

PostgreSQL выигрывает на сложных аналитических запросах (множественные JOIN, оконные функции, подзапросы), на нагрузках с высокой конкурентностью записи и при работе с большими объёмами данных. Его оптимизатор запросов — один из самых продвинутых среди open-source СУБД. PostgreSQL 18 с новой подсистемой AIO показывает ускорение до 3x для последовательных сканирований и bitmap heap scan.

-- PostgreSQL: аналитический запрос с оконными функциями
-- (работает быстрее за счёт продвинутого оптимизатора)
SELECT
    department,
    employee_name,
    salary,
    AVG(salary) OVER (PARTITION BY department) AS dept_avg,
    RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS rank_in_dept,
    salary - LAG(salary) OVER (PARTITION BY department ORDER BY hire_date) AS salary_growth
FROM employees
WHERE hire_date >= '2024-01-01'
ORDER BY department, rank_in_dept;

Работа с JSON и полуструктурированными данными

Оба движка поддерживают JSON, но реализации существенно различаются.

PostgreSQL: JSONB как полноценный тип данных

PostgreSQL хранит JSON в бинарном формате (JSONB), что позволяет индексировать отдельные ключи через GIN-индексы и выполнять эффективные запросы:

-- PostgreSQL: создание таблицы с JSONB
CREATE TABLE events (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    data JSONB NOT NULL,
    created_at TIMESTAMPTZ DEFAULT now()
);

-- GIN-индекс для поиска по любому ключу внутри JSON
CREATE INDEX idx_events_data ON events USING GIN (data);

-- Поиск по вложенным ключам
SELECT id, data->>'event_type' AS event_type
FROM events
WHERE data @> '{"source": "mobile", "version": 2}'
  AND data->>'event_type' = 'purchase';

-- PostgreSQL 17+: JSON_TABLE для преобразования JSON в табличный формат
SELECT jt.*
FROM events,
     JSON_TABLE(data, '$' COLUMNS (
         event_type TEXT PATH '$.event_type',
         user_id INT PATH '$.user_id',
         amount NUMERIC PATH '$.amount'
     )) AS jt
WHERE created_at > now() - INTERVAL '1 day';

MySQL: JSON с функциональными индексами

MySQL хранит JSON в бинарном формате, но использует функциональные индексы (virtual generated columns) для индексирования конкретных путей:

-- MySQL: создание таблицы с JSON
CREATE TABLE events (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    data JSON NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    -- Виртуальный столбец для индексирования
    event_type VARCHAR(50) GENERATED ALWAYS AS (data->>'$.event_type') VIRTUAL,
    INDEX idx_event_type (event_type)
);

-- Поиск по JSON-пути
SELECT id, data->>'$.event_type' AS event_type
FROM events
WHERE JSON_CONTAINS(data, '{"source": "mobile"}')
  AND data->>'$.event_type' = 'purchase';

Ключевое различие: PostgreSQL позволяет индексировать весь JSON-документ одним GIN-индексом (оператор @>), а MySQL требует создания виртуальных столбцов для каждого индексируемого пути. Для приложений с динамической JSON-схемой (логи, события, конфигурации) PostgreSQL значительно удобнее.

Репликация и высокая доступность

PostgreSQL: логическая и физическая репликация

PostgreSQL поддерживает два типа репликации:

• Физическая (streaming) репликация — побайтовая копия WAL-сегментов. Реплика — точная копия мастера. Подходит для HA-кластеров.
• Логическая репликация — передача изменений на уровне строк. Позволяет реплицировать отдельные таблицы, фильтровать данные, делать мажорные апгрейды без простоя.

В PostgreSQL 18 логическая репликация получила значительные улучшения, упрощающие мажорные апгрейды и управление HA-кластерами. Инструменты HA: Patroni, repmgr, pg_auto_failover.

-- PostgreSQL: настройка логической репликации
-- На мастере:
CREATE PUBLICATION my_pub FOR TABLE orders, customers;

-- На реплике:
CREATE SUBSCRIPTION my_sub
    CONNECTION 'host=master dbname=mydb'
    PUBLICATION my_pub;

MySQL: Group Replication и InnoDB Cluster

MySQL предлагает три модели репликации:

• Async replication — классическая мастер-слейв репликация через binary log.
• Semi-sync replication — мастер ждёт подтверждения от хотя бы одного слейва.
• Group Replication — встроенный протокол Paxos для multi-master или single-primary конфигурации. Основа InnoDB Cluster.

InnoDB Cluster = Group Replication + MySQL Shell + MySQL Router — это готовое HA-решение от Oracle:

-- MySQL: создание InnoDB Cluster через MySQL Shell
-- mysqlsh
dba.createCluster('myCluster');
cluster.addInstance('root@replica1:3306');
cluster.addInstance('root@replica2:3306');
cluster.status();

Обе СУБД предоставляют надёжные инструменты для HA, но экосистема PostgreSQL более открыта и модульна, тогда как MySQL предлагает более «коробочное» решение через InnoDB Cluster.

Полнотекстовый поиск

PostgreSQL имеет встроенную поддержку полнотекстового поиска с лексерами, словарями, ранжированием и поддержкой многих языков, включая русский:

-- PostgreSQL: полнотекстовый поиск на русском
ALTER TABLE articles ADD COLUMN search_vector tsvector;

UPDATE articles SET search_vector =
    to_tsvector('russian', coalesce(title, '') || ' ' || coalesce(body, ''));

CREATE INDEX idx_articles_search ON articles USING GIN (search_vector);

-- Поиск с ранжированием
SELECT title, ts_rank(search_vector, query) AS rank
FROM articles, to_tsquery('russian', 'PostgreSQL & производительность') AS query
WHERE search_vector @@ query
ORDER BY rank DESC
LIMIT 10;

MySQL реализует полнотекстовый поиск через FULLTEXT-индексы, но с ограниченной поддержкой языков и менее гибким ранжированием:

-- MySQL: полнотекстовый поиск
ALTER TABLE articles ADD FULLTEXT INDEX ft_idx (title, body);

SELECT title, MATCH(title, body) AGAINST('PostgreSQL performance' IN BOOLEAN MODE) AS score
FROM articles
WHERE MATCH(title, body) AGAINST('PostgreSQL performance' IN BOOLEAN MODE)
ORDER BY score DESC
LIMIT 10;

Для русскоязычных проектов PostgreSQL — однозначно лучший выбор благодаря встроенной поддержке морфологии русского языка.

Сводная таблица сравнения

Критерий	PostgreSQL 18	MySQL 8.4 LTS / 9.x
Лицензия	PostgreSQL License (MIT-подобная)	GPL v2 (Community), проприетарная (Enterprise)
Модель процессов	Процессы (fork)	Потоки
Соответствие SQL-стандарту	SQL:2023, наиболее полная реализация	Частичная, со своими расширениями
JSON	JSONB + GIN-индексы, JSON_TABLE	JSON + виртуальные столбцы
Полнотекстовый поиск	Встроенный, многоязычный (русский)	FULLTEXT, ограниченная локализация
Расширяемость	Расширения, пользовательские типы, индексы	Подключаемые движки (практически только InnoDB)
Репликация	Физическая + логическая	Async, semi-sync, Group Replication
Партиционирование	Декларативное (range, list, hash)	Range, list, hash, key
MVCC	Полная реализация, версии в heap	InnoDB undo log
Пулинг соединений	Внешний (PgBouncer, Odyssey)	Встроенный thread pool (Enterprise)
Векторный поиск	pgvector (расширение)	Тип VECTOR (9.0+, базовый)
HA «из коробки»	Patroni / repmgr (внешние)	InnoDB Cluster (встроенный)
Docker Hub загрузок	1B+	1B+
SO Survey 2025	55,6% разработчиков	40,5% разработчиков
DB-Engines (сент. 2025)	#4 (657 баллов, растёт)	#2 (1 450+ баллов)

Экосистема и инструменты

PostgreSQL

Экосистема PostgreSQL в 2026 году охватывает практически все современные потребности:

• ORM и драйверы: поддержка во всех основных ORM — SQLAlchemy, Django ORM, ActiveRecord, Prisma, Drizzle, TypeORM, GORM. Нативные драйверы для каждого языка (psycopg3, node-postgres, pq для Go).
• Облачные сервисы: Amazon RDS/Aurora PostgreSQL, Google Cloud SQL, Azure Database for PostgreSQL, Supabase (BaaS на базе Postgres), Neon (serverless PostgreSQL), CockroachDB (распределённый Postgres-совместимый).
• Расширения: PostGIS (геоданные), TimescaleDB (временные ряды), pgvector (ML/AI), Citus (шардинг), pg_cron (задачи по расписанию), pgAudit (аудит).
• GUI: pgAdmin 4, DBeaver, DataGrip, Beekeeper Studio.

MySQL

• ORM и драйверы: полная поддержка в Sequelize, TypeORM, Prisma, Django ORM, ActiveRecord, GORM. MySQL Connector для Java, Python, .NET, Node.js.
• Облачные сервисы: Amazon RDS/Aurora MySQL, Google Cloud SQL, Azure Database for MySQL, PlanetScale (serverless MySQL на базе Vitess), TiDB (распределённый MySQL-совместимый).
• Инструменты: MySQL Workbench (официальная IDE), Percona Toolkit (оптимизация), ProxySQL (пулинг и роутинг), Vitess (шардинг, используется YouTube, Slack).
• CMS и фреймворки: WordPress (43% всех сайтов), Drupal, Joomla, Laravel, Ruby on Rails — исторически работают на MySQL.

Рынок труда и популярность

По данным анализа вакансий за 2025 год, MySQL упоминается в 32,85% вакансий, связанных с базами данных, а PostgreSQL — в 28,59%. Однако тренд очевиден: доля PostgreSQL в вакансиях растёт на 3-5% ежегодно, тогда как MySQL стабилен или снижается.

Stack Overflow Developer Survey 2025 фиксирует разрыв в 15 процентных пунктов в пользу PostgreSQL по использованию среди разработчиков (55,6% против 40,5%). PostgreSQL также лидирует в категориях «Desired» (хотят использовать) и «Admired» (нравится тем, кто использует) третий год подряд.

Средняя зарплата SQL-специалистов в США составляет $70 000–$120 000, при этом специалисты по PostgreSQL в среднем зарабатывают на 5-10% больше благодаря спросу на сложные аналитические и enterprise-системы.

Когда выбрать PostgreSQL

PostgreSQL — оптимальный выбор в следующих сценариях:

1. Сложные аналитические запросы — оконные функции, рекурсивные CTE, LATERAL JOIN, JSON-агрегация. Оптимизатор Postgres справляется с ними значительно лучше.
2. Геоданные и ГИС — PostGIS делает PostgreSQL стандартом de facto для геоинформационных систем.
3. Полуструктурированные данные — JSONB с GIN-индексами позволяет строить гибридные реляционно-документные модели.
4. ML/AI и векторный поиск — pgvector зрелее и быстрее, чем нативный VECTOR в MySQL.
5. Строгие требования к целостности — CHECK constraints, exclusion constraints, temporal constraints (PG 18), deferred constraints.
6. Полнотекстовый поиск на русском — встроенная поддержка русской морфологии без внешних зависимостей.
7. Стартапы и новые проекты — Supabase, Neon, Railway и другие современные платформы строятся на PostgreSQL.
8. Расширяемость — если вам нужны пользовательские типы данных, операторы или индексные методы.

-- PostgreSQL: пример гибридной реляционно-документной модели
CREATE TABLE products (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name TEXT NOT NULL,
    price NUMERIC(10,2) NOT NULL,
    attrs JSONB DEFAULT '{}',
    location GEOGRAPHY(Point, 4326),  -- PostGIS
    search_vector tsvector,
    embedding vector(384)              -- pgvector
);

-- Один запрос, использующий все возможности
SELECT name, price,
       attrs->>'color' AS color,
       ST_Distance(location, ST_MakePoint(37.6173, 55.7558)::geography) AS distance_m
FROM products
WHERE attrs @> '{"category": "electronics"}'
  AND search_vector @@ to_tsquery('russian', 'смартфон')
ORDER BY embedding <-> '[0.1, 0.2, ...]'::vector
LIMIT 5;

Когда выбрать MySQL

MySQL остаётся отличным выбором в следующих сценариях:

1. Read-heavy веб-приложения — блоги, CMS, интернет-магазины с преобладанием чтения. InnoDB Buffer Pool эффективно кеширует горячие данные.
2. WordPress и PHP-экосистема — WordPress, Laravel, Symfony, Drupal — всё это традиционно работает на MySQL, и менять стек ради смены СУБД нецелесообразно.
3. Готовое HA-решение — InnoDB Cluster предоставляет multi-master репликацию «из коробки», без необходимости настраивать Patroni или etcd.
4. Горизонтальное масштабирование — Vitess (MySQL sharding, используется YouTube, Slack, GitHub) и PlanetScale — зрелые решения для шардинга MySQL.
5. Команда с MySQL-экспертизой — если ваша команда десять лет работает с MySQL, стоимость миграции может перевесить технические преимущества PostgreSQL.
6. Legacy-системы — миллионы существующих приложений работают на MySQL, и миграция не всегда оправдана.

-- MySQL: типичная конфигурация для веб-приложения
-- my.cnf (оптимизация для read-heavy нагрузки)
-- [mysqld]
-- innodb_buffer_pool_size = 4G
-- innodb_buffer_pool_instances = 4
-- innodb_read_io_threads = 8
-- innodb_write_io_threads = 4
-- innodb_log_file_size = 1G

-- Пример запроса для интернет-магазина
SELECT p.id, p.name, p.price, c.name AS category,
       (SELECT AVG(r.rating) FROM reviews r WHERE r.product_id = p.id) AS avg_rating
FROM products p
JOIN categories c ON p.category_id = c.id
WHERE p.is_active = 1
  AND p.price BETWEEN 1000 AND 5000
ORDER BY avg_rating DESC
LIMIT 20;

Миграция между PostgreSQL и MySQL

Если вы решили мигрировать с MySQL на PostgreSQL (или наоборот), учтите основные различия в синтаксисе:

MySQL	PostgreSQL	Комментарий
AUTO_INCREMENT	GENERATED ALWAYS AS IDENTITY	PG также поддерживает SERIAL (deprecated)
TINYINT(1) для boolean	BOOLEAN (настоящий тип)	MySQL хранит как число 0/1
ENUM('a','b','c')	CREATE TYPE ... AS ENUM	PG: отдельный тип в каталоге
IFNULL()	COALESCE()	COALESCE — стандарт SQL
GROUP_CONCAT()	STRING_AGG()	Различный синтаксис
NOW()	now() или CURRENT_TIMESTAMP	Семантически одинаково
LIMIT offset, count	LIMIT count OFFSET offset	Порядок аргументов различается
Backticks ` для идентификаторов	Двойные кавычки "	PG также принимает без кавычек (lowercase)

Инструменты для миграции: pgLoader (MySQL → PostgreSQL, самый зрелый), AWS DMS (Database Migration Service), Bytebase (schema change management для обеих СУБД).

Заключение

В 2026 году PostgreSQL и MySQL — это два зрелых, надёжных, production-ready решения, и любое из них способно обслуживать нагрузки от стартапа до Fortune 500. Тем не менее, тренды очевидны.

PostgreSQL стал выбором по умолчанию для новых проектов. Он лидирует по популярности среди разработчиков, превосходит MySQL по функциональности (JSONB, полнотекстовый поиск, расширяемость, стандарты SQL), демонстрирует лучшую производительность на сложных запросах и аналитических нагрузках. Экосистема облачных сервисов вокруг Postgres (Supabase, Neon, CockroachDB) растёт быстрее, чем вокруг MySQL. Если вы начинаете проект с чистого листа и у вас нет специфических причин выбрать MySQL — выбирайте PostgreSQL.

MySQL остаётся отличным выбором для read-heavy веб-приложений, WordPress-экосистемы, проектов с потребностью в горизонтальном шардинге (Vitess, PlanetScale) и команд с накопленной MySQL-экспертизой. Переезжать с MySQL на PostgreSQL ради моды не стоит — но для новых проектов стоит серьёзно рассмотреть Postgres.

Оба проекта активно развиваются: PostgreSQL 18 принёс асинхронный I/O и uuidv7, MySQL 9.x — VECTOR-тип и JavaScript-хранимые процедуры. Конкуренция между ними идёт на пользу всему сообществу open-source баз данных.

Источники

1. PostgreSQL 18 Released — официальный релиз
2. MySQL 9.2 Release Notes — Oracle
3. Stack Overflow Developer Survey 2025 — Technology
4. MySQL vs PostgreSQL Performance — binaryigor.com
5. PostgreSQL vs MySQL: Which Database Should You Choose in 2026 — Bytebase
6. PostgreSQL vs MySQL: In-depth Comparison — EnterpriseDB
7. What’s New in PostgreSQL 18 — Neon