Миграция баз данных в 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/репликацию/бэкапы классическими средствами.

UPD: ответы на частые вопросы из комментариев

Спасибо всем, кто не поленился разобрать методику и ткнуть в слабые места. Ниже — ответы на самые частые и справедливые вопросы, чтобы было понятнее, что именно я сравнивал и где границы применимости выводов.

---

UPD: ответы на частые вопросы из комментариев

Про TLS и «сравнение в молоко»

«Tls? Ну, камон, базу без TLS запускать в 2025…»

В тестах TLS был включён и на VM, и в cnpg:

• на VM: ssl = on, стандартные сертификаты Ubuntu;

• в cnpg: ssl = 'on', ca/cert/key от оператора, ssl_min_protocol_version = 'TLSv1.3'.

Клиент (pgbench) — отдельная VM в том же облаке, в обоих вариантах ходит по TCP+TLS.
Никаких Unix-сокетов и «нечестного» локального доступа в случае native-VM не было.

---

Где крутился pgbench и какой сетевой путь

Сетевой путь во всех тестах был таким:

• pgbench на отдельной VM в YC;

• дальше — через сеть провайдера до:

  • VM с PostgreSQL (native), либо

  • ноды кластера YC Managed Kubernetes с cnpg (Service → kube-proxy/CNI → Pod).

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

• база живёт на отдельной VM или в k8s,

• приложение/клиент — на другой VM/ноде, а не на том же хосте.

Сценарий «pgbench в k8s, в том же namespace/кластере, что и БД» — валидный и интересный, но в эту статью не попал.

---

Шумные соседи, taints/tolerations, QoS

«А ничего, что на ноде кластера куча сервисов?»
«numa? cpu pinning? guaranteed qos class?»

В рамках этих тестов я старался максимально «почистить» окружение:

• для cnpg была выделенная нода в кластере YC Managed Kubernetes;

• на ноде висели taints, а Pod cnpg имел соответствующие tolerations;

• все служебные Pod’ы (логи, метрики и т.п.) были сжаты по requests/limits, чтобы шум от них был минимален;

• Pod cnpg получил гарантированные реквесты CPU/RAM, эквивалентные ресурсам native VM.

Чего не было сделано:

• NUMA pinning (привязка конкретных ядер),

• CPU Manager / dedicated CPU pool,

• ручной тюнинг планировщика Linux (sysctl, sched_*, I/O scheduler и т.д.),

• игра с QoS Guaranteed с жёстким cpu-pinning.

И это, правда, важный момент:
я сравнивал не «идеально вытюнинганный k8s против идеально вытюнинганной VM», а два варианта «as is, но с минимальным здравым тюнингом». в рамках конкретного облачного провайдера - Yandex Cloud

---

Конфиги PostgreSQL: одинаковые или нет?

«Автор использует по-разному настроенные PostgreSQL»

Изначальный postgresql.conf на VM действительно был почти дефолтным, но боевой конфиг живёт в conf.d/custom.conf. Для честного сравнения я привёл его к тому, что генерирует cnpg:

На VM (conf.d/custom.conf):

listen_addresses = '*'
max_connections = 5000

shared_buffers = 10GB

max_wal_senders = 20
wal_level = logical
archive_mode = on
logging_collector = on

shared_preload_libraries = 'pg_stat_statements'

В cnpg (custom.conf от оператора):

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

shared_buffers = '10GB'
wal_level = 'logical'
archive_mode = 'on'
logging_collector = 'on'

ssl = 'on'
...
max_worker_processes = '32'
max_parallel_workers = '32'
max_replication_slots = '32'
wal_keep_size = '512MB'
wal_log_hints = 'on'

То есть:

• ключевые вещи, влияющие на нагрузку pgbench (соединения, shared_buffers, wal_level, archive_mode, TLS) — синхронизированы;

• различия остались в «операторной навеске» (wal_keep_size, max_parallel_workers, логирование в csvlog и пр.).

Я осознанно не пытался «подбить» стендалон PostgreSQL под побитовый клон cnpg-конфига — задача статьи была показать, что получится, если:

«Мы берём наш боевой конфиг Postgres, поднимаем его на VM и поднимаем его же в cnpg в YC — что будет с TPS?»

---

Почему не сравнивал с Managed PostgreSQL в Yandex Cloud

«А чего тогда вообще с managed db не сравнить?»

Есть две причины:

1. Практическая. Я выбирал между:

   • self-managed VM+Postgres и

   • self-managed cnpg в k8s,

   потому что так устроена моя инфраструктура и процессы.

2. Методологическая. У YC Managed PostgreSQL есть:

   • закрытые от пользователя оптимизации (ядро, диски, настройки),

   • и одновременно — жёсткие ограничения (например, лимиты на коннекты на ядро).

Это делает сравнение «VM vs cnpg vs MDB» гораздо менее прозрачным: мы уже сравниваем не только Postgres/среду, но и «сколько тюнинга за нас сделал провайдер».

В отдельной статье можно устроить именно «битву трёх миров» (VM, cnpg, MDB), но это будет уже другой эксперимент с другой постановкой задачи.

---

JIT, пулер соединений, тюнинг ОС

• JIT. Я не выключал JIT явно ни там, ни там, оставил дефолты.

  • Для типичных pgbench-запросов (простые короткие SQL) JIT обычно и так не включается из-за порога по стоимости.

  • То есть влияние JIT на итоговые TPS в данном конкретном тесте — минимальное и одинаковое.

• Пулеры (pgbouncer и пр.). Не использовались специально, чтобы:

  • не вносить дополнительный слой буферизации/лимитов,

  • мерить именно поведение «голого» PostgreSQL под нагрузкой.

• Тюнинг ОС.

  • На VM — стандартный образ Ubuntu из YC, без глубокого ручного тюнинга sysctl, I/O-планировщика и т.п.

  • На нодах k8s — стандартные настройки Managed Kubernetes от Yandex Cloud (как есть).

Это осознанный компромисс: сравнение двух реалистичных, но не «вылизанных до упора» сетапов, максимально похожих на то, как это часто делается в жизни.

---

Что на самом деле утверждает эта статья

Я не утверждаю, что:

• «PostgreSQL в Kubernetes всегда медленнее на 40%»;

• «cnpg плохой/непригодный»;

• «VM — единственно правильный путь».

Я утверждаю только следующее:

1. В моём кейсе (Yandex Cloud, PostgreSQL 14, одинаковый конфиг и ресурсы, pgbench с внешней VM, cnpg в YC Managed k8s)
   я стабильно вижу 20–40% просадки TPS у cnpg относительно native-VM.

2. fio показывает, что диски сами по себе не виноваты (особенно на ssd-io),
   а значит, существенная часть overhead’а лежит в:

   • сетевом пути (Service/kube-proxy/CNI),

   • контейнерной обвязке (cgroups, планировщик, доп. контекст-свитчи),

   • операторной конфигурации.

3. Для моих задач и моих SLO такой overhead — неприемлем, поэтому я отказался от миграции на cnpg именно в текущем виде.

И да — я полностью согласен с теми, кто пишет, что:

• чтобы «докопаться до истины», нужно:

  • вынести Postgres в отдельный pod без оператора,

  • поиграть с hostNetwork и CNI,

  • включить CPU pinning / QoS guaranteed / NUMA-тюнинг,

  • прогнать дополнительные сценарии (в т.ч. pgbench внутри кластера),

• и тогда мы сможем точнее разделить:

  • «что даёт k8s/контейнеры»,

  • «что даёт оператор cnpg»,

  • «что даёт конкретный облачный провайдер».