Миграция баз данных в Kubernetes выглядит логичным шагом: хочется операторов, GitOps, автопочинку, единый способ доставки и управления. Для PostgreSQL один из популярных вариантов — CloudNativePG.

Но как только разговор доходит до продакшена, возникает очень приземлённый вопрос:

Сколько производительности я потеряю по сравнению с “голым” PostgreSQL на виртуалке?

В этой статье я воспроизвёл максимально честное сравнение:

• native PostgreSQL на VM в Yandex Cloud;

• CloudNativePG-кластер в Kubernetes в том же Yandex Cloud;

• одинаковые конфиги PostgreSQL и схожие ресурсы;

• тесты диска через fio и тесты PostgreSQL через pgbench.

Важное уточнение про стенд:

• pgbench запускался с отдельной VM (то есть “локальная машина” клиента нагрузки — это тоже VM в YC).

• И native PostgreSQL, и CloudNativePG — это удалённые PostgreSQL-серверы, до которых мы ходим по сети (TCP).

• Сравнивается именно “сетевой клиент → VM с Postgres” против “сетевой клиент → Kubernetes-кластер с Postgres (CloudNativePG)”.

В итоге картинка получилась довольно типичной для продакшена: выигрыши в удобстве и управляемости Kubernetes есть, но платить за них приходится просадкой до ~40% по TPS.

Далее — подробности

---

Тесты производительности

Исходные данные

• Облако: Yandex Cloud.

• PostgreSQL: v14.

• Конфиги PostgreSQL и ресурсы максимально выровнены между:

  • native Postgres VM;

  • CloudNativePG-кластером.

• Хранилище:

  • native-vm — VM на yc-network-ssd, 533 GiB.

  • cnpg-yc-network-ssd — CloudNativePG (PVC на yc-network-ssd), 533 GiB.

  • cnpg-yc-network-ssd-io-m3 — CloudNativePG (PVC на yc-network-ssd-io-m3), 558 GiB (кратность 93 GiB — ограничение Yandex Cloud).

---

Конфигурация PostgreSQL

Native PostgreSQL (VM)

Базовый конфиг - главное:

listen_addresses = '*'
port = 5432
max_connections = 5000

shared_buffers = 10GB

wal_level = logical
archive_mode = on
max_wal_senders = 20

logging_collector = on

ssl = on
shared_preload_libraries = 'pg_stat_statements'

Остальное — дефолты Debian/Ubuntu для PostgreSQL 14.

CloudNativePG (Pod внутри кластера)

custom.conf внутри Pod’а CloudNativePG:

cluster_name = 'db-stage-cnpg'

listen_addresses = '*'
port = '5432'
max_connections = '5000'

shared_buffers = '10GB'

wal_level = 'logical'
archive_mode = 'on'
archive_command = '/controller/manager wal-archive --log-destination /controller/log/postgres.json %p'
wal_keep_size = '512MB'

max_replication_slots = '32'
max_worker_processes = '32'
max_parallel_workers = '32'

ssl = 'on'
ssl_ca_file = '/controller/certificates/client-ca.crt'
ssl_cert_file = '/controller/certificates/server.crt'
ssl_key_file = '/controller/certificates/server.key'
ssl_min_protocol_version = 'TLSv1.3'
ssl_max_protocol_version = 'TLSv1.3'

logging_collector = 'on'
log_destination = 'csvlog'
log_directory = '/controller/log'
log_filename = 'postgres'

То есть:

• По памяти и WAL (shared_buffers, max_connections, wal_level, archive_mode) конфиги приведены к одному виду.

• CNPG добавляет:

  • жёсткий TLS 1.3;

  • собственный archive_command;

  • служебную обвязку оператора.

---

Методология тестирования

fio: как и зачем именно так

Цель fio — отделить “чистую” производительность диска от влияния PostgreSQL и Kubernetes.

Я тестировал три сценария:

1. Random 80% read / 20% write (randrw_80_20_file)

   • Блок 8k — соответствует странице PostgreSQL.

   • 80/20 по чтению/записи — типичный OLTP-паттерн.

   • direct=1 — обходим page cache, тестируем именно диск/блоковое устройство.

   • size=50G, runtime=300, numjobs=4, iodepth=32 — даём диску выйти на плато по IOPS.

2. Последовательное чтение (seq_read_file)

   • bs=1M — имитация больших чтений (бэкапы, аналитику, последовательные сканы).

   • runtime=300, iodepth=16 — устойчивое измерение пропускной способности.

3. Последовательная запись (seq_write_file)

   • Тоже bs=1M, сценарии bulk-загрузки/бэкапов/логирования.

Эти тесты запускались на том же томе, где лежат данные PostgreSQL:

• на VM — это диск под /var/lib/postgresql;

• в CNPG — это PVC, примонтированный в Pod.

Конфигурация fio в виде job-файла (в статье можно привести так):

[randrw_80_20_file]
direct=1
bs=8k
size=50G
time_based=1
runtime=300
ioengine=libaio
iodepth=32
end_fsync=1
log_avg_msec=1000
directory=/data
rw=randrw
rwmixread=80
write_bw_log=randrw_80_20_file
write_lat_log=randrw_80_20_file
write_iops_log=randrw_80_20_file

[seq_read_file]
direct=1
bs=1M
size=50G
time_based=1
runtime=300
ioengine=libaio
iodepth=16
end_fsync=1
log_avg_msec=1000
directory=/data
rw=read
write_bw_log=seq_read_file
write_lat_log=seq_read_file
write_iops_log=seq_read_file

[seq_write_file]
direct=1
bs=1M
size=50G
time_based=1
runtime=300
ioengine=libaio
iodepth=16
end_fsync=1
log_avg_msec=1000
directory=/data
rw=write
write_bw_log=seq_write_file
write_lat_log=seq_write_file
write_iops_log=seq_write_file

Где /data — это директория на томе, который мы сравниваем (VM vs PVC).

---

pgbench: как и зачем именно так

Задача pgbench — померить итоговую производительность PostgreSQL, уже с учётом:

• сетевой задержки,

• оверхеда Kubernetes,

• внутренних накладных расходов Postgres.

Я проверял 4 сценария:

1. In-memory | read-only

   • scale = 100 — рабочий набор данных полностью помещается в shared_buffers = 10GB.

   • Транзакции только на чтение (read-only), без модификаций.

   • Имитирует горячий кэш и активные сервисы читающего характера.

2. In-memory | read-write

   • Тот же scale = 100.

   • Стандартный сценарий pgbench с UPDATE/INSERT.

   • Нагрузка, близкая к типичному OLTP с модификациями.

3. Disk-bound | read-only

   • scale = 300 — часть данных уже “холодная”, без полного попадания в память.

   • Тестируем вместе диск, планировщик, кеш-менеджер.

4. Disk-bound | read-write

   • Тот же scale = 300, но с записью.

Для каждого сценария я прогонял pgbench с разным числом клиентов:

• In-memory: 8, 16, 32, 64, 128 соединений.

• Disk-bound: 8, 16, 32 соединения.

Далее для каждой связки “сценарий + профиль окружения” я брал максимальное достигнутое значение TPS (по какому-то числу клиентов) и сравнивал их между собой.

Типовая команда выглядела примерно так:

# Подготовка:
pgbench -h <host> -p 5432 -U <user> -i -s 100 pgbench

# Пример прогона in-memory read-only:
pgbench -h <host> -p 5432 -U <user> \
  -s 100 \
  -c 32 \
  -T 60 \
  -M simple \
  -S

И отдельно такие же прогоны для:

• -s 300 для disk-bound;

• без -S для read-write сценариев.

Важно: одна и та же клиентская VM использовалась для всех тестов (native-vm и оба профиля CNPG), чтобы не подмешивать отличия сети/клиента.

---

Дисковая подсистема — результаты fio

Подробные результаты fio

fio — итоги

Ключевое наблюдение:

• cnpg-yc-network-ssd по диску не хуже VM, а по латенсиям местами даже лучше.

• cnpg-yc-network-ssd-io-m3 по диску заметно лучше, чем VM (до 1.7–4× по разным метрикам).

Если смотреть только на диск, Kubernetes/CloudNativePG ничего не ломают — наоборот, ssd-io даёт серьёзный запас по I/O.

---

PostgreSQL — результаты pgbench

Run 1 — native-vm

1. memory | read-only

2. memory | read-write

3. disk-bound | read-only (scale=300)

4. disk-bound | read-write (scale=300)

---

Run 2 — cnpg-yc-network-ssd

1. memory | read-only

2. memory | read-write

3. disk-bound | read-only (scale=300)

4. disk-bound | read-write (scale=300)

---

Run 3 — cnpg-yc-network-ssd-io-m3

1. memory | read-only

2. memory | read-write

3. disk-bound | read-only (scale=300)

4. disk-bound | read-write (scale=300)

---

Сводная таблица по pgbench

1. Overview (максимальный TPS по сценарию)

2. Деградация vs native-vm (по максимальному TPS)

Падение производительности относительно Run 1 — native-vm, в процентах (чем больше число, тем хуже).

3. Итоги по pgbench

• Перенос в Kubernetes на network-ssd даёт ~20–40% деградации по TPS относительно native PostgreSQL на VM.

• Переход на ssd-io (b3-m3) улучшает диски, но не улучшает TPS.

• Напротив, отставание от native-vm ещё усиливается: до ~38–47% ниже по пиковому TPS во всех сценариях.

---

Как ходит запрос: VM vs Kubernetes

Хочется наглядно показать, где возникает дополнительный оверхед.

1. Путь до native PostgreSQL на VM

• pgbench живёт на отдельной VM в Yandex Cloud.

• Подключается по TCP к VM с PostgreSQL.

• На стороне БД:

  • нет kube-proxy, Service, Pod-сети;

  • только сеть YC + процесс postgres.

[pgbench VM]
      |
      |  TCP (иногда TLS, в зависимости от настроек)
      v
+----------------------+
|  VM с PostgreSQL     |
|  (native, systemd)   |
+----------+-----------+
           |
           v
     postgres процесс

---

2. Путь до PostgreSQL в CloudNativePG

• Всё так же начинается с pgbench на отдельной VM.

• Подключение идёт к адресу Kubernetes Service (ClusterIP/LoadBalancer).

• Далее:

  • kube-proxy / iptables;

  • выбор Pod’а;

  • Pod-сеть;

  • контейнер с PostgreSQL.

• Плюс к этому:

  • TLS 1.3 по умолчанию (по конфигу CNPG);

  • дополнительные процессы/обвязка (WAL-архивер, контроллер CNPG и т.д.).

[pgbench VM]
      |
      |  TCP (TLS)
      v
+-------------------------+
|  Yandex Cloud сеть      |
+-----------+-------------+
            |
            v
+-------------------------+
|  Node Kubernetes        |
|  (kubelet, kube-proxy)  |
+-----------+-------------+
            |
            v
   iptables / kube-proxy
            |
            v
   ClusterIP Service
            |
            v
+-------------------------+
|  Pod: PostgreSQL (CNPG) |
|  контейнер postgres     |
+-------------------------+

---

Почему такие просадки и что с этим делать?

1. По дискам CNPG не хуже VM, а на ssd-io даже существенно лучше.

2. Конфиги PostgreSQL по сути одинаковые:

   • те же shared_buffers = 10GB,

   • max_connections = 5000,

   • wal_level = logical,

   • включённый archive_mode.

3. Тесты выполнялись с одной и той же клиентской VM, по сети, без Unix-socket.

Основные источники просадки:

1. Сетевой оверхед Kubernetes

• Дополнительные hop’ы:

  • вход на Node;

  • kube-proxy/iptables;

  • кластерная сеть;

  • Pod-сеть.

• Каждый hop добавляет задержку и системные вызовы.

• В in-memory тестах, где диск не является узким местом, именно эти накладные расходы становятся доминирующими.

2. TLS и его цена

• В CNPG TLS 1.3 строгий и завязан на внутреннюю PKI оператора.

• В native-vm SSL тоже включён, но сочетание протокола/шифров отличается.

• При большом числе одновременных соединений шифрование становится заметной составляющей.

3. Контейнерное окружение

• cgroups, лимиты и возможный CPU throttling;

• шум от соседних Pod’ов на ноде;

• дополнительные слои сетевой абстракции (veth, bridge/overlay).

4. Оверхед оператора и служебных компонентов

• фоновые процессы CNPG;

• WAL-архивер (дополнительная работа с WAL);

• мониторинг, метрики, служебные запросы.

Все эти эффекты:

• сложно вылечить простым тюнингом postgresql.conf;

• плохо диагностируются простыми средствами (на графиках видно “есть просадка”, а где именно она рождается — уже отдельное исследование).

---

Выводы

1. Что говорят цифры

• По данным fio:

  • CNPG на yc-network-ssd ≈ VM по диску;

  • CNPG на yc-network-ssd-io-m3 существенно быстрее VM по I/O.

• По данным pgbench:

  • Перенос PostgreSQL в Kubernetes (CloudNativePG + network-ssd) даёт ~20–40% деградации по TPS.

  • Переход на более быстрый диск (ssd-io) не возвращает TPS, а отставание от native-vm даже растёт до ~38–47%.

2. Практическая интерпретация

Если для вашего проекта:

• критичны TPS и latency,

• а плюшки Kubernetes (оператор, GitOps, единый пайплайн для приложений и БД) не являются обязательными,

то:

Native PostgreSQL на VM в Yandex Cloud даёт более предсказуемую и высокую производительность.

CloudNativePG приносит:

• удобный декларативный подход к управлению кластерами,

• автоматизацию репликации и failover,

• лучшее встраивание в Kubernetes-процессы.

Но за это приходится платить существенной ценой в производительности, особенно заметной при in-memory нагрузках и большом количестве запросов.

3. Решение по итогам тестов

В моём кейсе:

• Конфиги PostgreSQL на native и CNPG сравнены и выровнены.

• Storage “в лоб” либо сопоставим, либо лучше под CNPG.

• Основной вклад в просадку TPS вносят:

  • сетевые hop’ы,

  • TLS,

  • контейнерное окружение и шум от соседей,

  • служебная обвязка оператора.

Полученная просадка до ~40% TPS для проекта критична.

Для данного проекта я отказался от использования CloudNativePG и оставил PostgreSQL на VM в Yandex Cloud, реализуя HA/репликацию/бэкапы классическими средствами.