Есть известная формула из PostgreSQL wiki и HikariCP wiki:

connections = (core_count * 2) + effective_spindle_count

core_count - ядра сервера базы, не приложения. Hyper-threading лучше не считать как полноценные ядра.

effective_spindle_count - грубая поправка на дисковую подсистему. Для современных SSD/NVMe часто берут 0 или 1 как стартовое приближение.

Пример:

PostgreSQL: 8 физических ядер, SSD
pool target ~= (8 * 2) + 1 = 17 активных соединений

Звучит мало. Особенно если у вас 500 RPS.

Но соединения к базе это не пользователи и не HTTP-запросы. Если запрос к базе занимает 20 мс, то 10 соединений теоретически могут прокачать сотни операций в секунду. А если запрос занимает 2 секунды, пул на 100 соединений не спасёт. Он просто даст ста людям одновременно страдать внутри базы.

Есть ещё один полезный способ думать: Little’s Law.

нужные соединения ~= RPS * среднее время работы с БД

Если сервис делает 300 DB-операций в секунду, а среднее время удержания соединения 30 мс:

300 * 0.03 = 9 соединений

Добавили запас, проверили p95/p99, прогнали нагрузочный тест. Получили стартовую настройку.

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

• заняты почти все соединения в пуле;

• потоки часто ждут свободное соединение;

• растёт количество ошибок по connection timeout;

• увеличивается время получения соединения из пула;

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

Если pending растёт, а база уже перегружена, увеличение пула сделает хуже. Это классика: приложение начинает давить сильнее ровно в тот момент, когда базе нужна передышка.

Один из самых частых продовых сюрпризов:

maximumPoolSize = 32
replicas = 12
итого потенциально 384 соединения к базе

А ещё есть миграции, админки, BI, cron jobs, ручные подключения, read-only сервисы. Потом кто-то удивляется, почему PostgreSQL внезапно выдает too many connections.

Размер пула надо считать не только на один процесс, а на всю систему:

db_connection_budget = 160
service_replicas = 8
pool_per_replica = 160 / 8 = 20

Если есть HPA (Horizontal Pod Autoscaler), берите максимальное количество pod’ов, а не комфортное среднее в обеденное время.

И да, иногда правильный ответ не “увеличить HikariCP”, а поставить PgBouncer или другой внешний pooler. Особенно когда много приложений, много коротких запросов и PostgreSQL страдает от числа backend-процессов.

PgBouncer это лёгкий внешний пулер соединений для PostgreSQL. Он стоит между приложениями и базой, принимает много клиентских подключений и переиспользует меньшее число реальных соединений к PostgreSQL.

Проще говоря, HikariCP управляет соединениями внутри одного JVM-приложения, а PgBouncer помогает ограничить общее количество соединений к базе на уровне инфраструктуры.

val config = new HikariConfig()
config.setJdbcUrl(url)
config.setUsername(user)
config.setPassword(password)
config.setMaximumPoolSize(connectionPoolMaxSize)
config.setLeakDetectionThreshold(1000)
config.setAutoCommit(true)
sslRootCert.foreach(config.addDataSourceProperty("sslrootcert", _))

new HikariDataSource(config)

Если проект всё ещё на HikariCP 3.4.5, это 2020 год. Для JVM-проекта в 2026 это уже техдолг.

Но обновление зависит от Java:

• Java 11+ - смотреть HikariCP 7.x или актуальную поддерживаемую линию фреймворка.

• Java 8 - не прыгать на 7.x, а сначала разобраться с совместимой веткой и планом миграции JVM.

• Java 21 + virtual threads - обязательно нагрузочное тестирование, особенно если соединения часто создаются и закрываются.

1000 мс выглядит как ошибка. Я бы сделал так:

if (leakDetectionEnabled) {
  config.setLeakDetectionThreshold(10_000)
}

И включал бы это через env/config только на время диагностики. Для постоянного прода лучше метрики плюс алерты на pending, timeout, usage.

Без имени пула метрики и логи хуже читаются.

config.setPoolName("app-postgres-main")

Название должно быть обезличенным, но понятным: сервис, база, роль. Если есть read-only пул, он должен называться иначе.

30 секунд по умолчанию я бы не оставлял.

config.setConnectionTimeout(5000)
config.setValidationTimeout(2000)

Для API 5 секунд это уже много. Для background jobs можно задать отдельно.

Например:

config.setMaxLifetime(25 * 60 * 1000)
config.setKeepaliveTime(2 * 60 * 1000)

Но эти числа нельзя копировать без проверки. Надо смотреть реальные таймауты PostgreSQL, cloud DB, firewall, NAT, proxy, PgBouncer, service mesh. maxLifetime должен быть чуть меньше внешнего лимита.

Если сервис online и нагрузка более-менее постоянная, я бы начал с fixed-size:

config.setMaximumPoolSize(poolSize)
config.setMinimumIdle(poolSize)

Если у сервиса бывают длинные периоды без нагрузки, а потом резкие всплески работы, можно оставить динамический пул, но тогда надо понимать latency на создание новых соединений.

Для Spring Boot это Actuator/Micrometer. Для ручной конфигурации:

config.setMetricRegistry(meterRegistry);

или JMX:

config.setRegisterMbeans(true);

Я бы не выпускал сервис в прод без графиков:

• active connections;

• idle connections;

• pending threads;

• connection acquire time;

• connection usage time;

• connection timeout count.

Не говорю, что 32 плохо. Может быть отлично. Но должно быть понятно, откуда взялось это число.

Минимальный sanity-check:

max_db_connections_for_service / max_replicas

Потом сверка с базой:

(db_cores * 2) + effective_spindle_count

Потом нужен нагрузочный тест. Без него сложно понять, подходит ли выбранный размер пула.

db.jdbc {
  dataSource {
    url = ${?DATASOURCE_URL}
    user = ${?DB_USER}
    password = ${?DB_PASSWD}
  }

  connectionPool {
    poolName = "app-postgres-main"
    maxSize = 16
    minIdle = 16
    connectionTimeoutMs = 5000
    validationTimeoutMs = 2000
    maxLifetimeMs = 1500000
    keepaliveTimeMs = 120000
    leakDetectionThresholdMs = 0
    registerMbeans = true
  }
}

val config = new HikariConfig()
config.setJdbcUrl(jdbc.url)
config.setUsername(jdbc.user)
config.setPassword(jdbc.password)

config.setPoolName(pool.poolName)
config.setMaximumPoolSize(pool.maxSize)
config.setMinimumIdle(pool.minIdle)
config.setConnectionTimeout(pool.connectionTimeoutMs)
config.setValidationTimeout(pool.validationTimeoutMs)
config.setMaxLifetime(pool.maxLifetimeMs)
config.setKeepaliveTime(pool.keepaliveTimeMs)
config.setLeakDetectionThreshold(pool.leakDetectionThresholdMs)
config.setRegisterMbeans(pool.registerMbeans)
config.setAutoCommit(true)

sslRootCert.foreach(config.addDataSourceProperty("sslrootcert", _))

new HikariDataSource(config)

В Java это try-with-resources.

try (Connection connection = dataSource.getConnection()) {
    // SQL work
}

В Spring - нормальные транзакции и отсутствие ручного удержания connection где попало.

В функциональных JVM-стеках - Resource, ZLayer и другие managed lifecycle-подходы. В Clojure - with-open, если берёте connection руками.

Перед тем как считать настройку HikariCP законченной, я бы прошёлся по такому списку:

• версия HikariCP совместима с Java и фреймворком;

• maximumPoolSize посчитан на все реплики, а не на один процесс;

• minimumIdle выбран осознанно: fixed-size или dynamic;

• connectionTimeout подходит под SLA сервиса;

• maxLifetime меньше внешних connection timeout’ов;

• keepaliveTime включён, если инфраструктура режет idle-соединения;

• leak detection выключен или включается для дебага;

• есть poolName;

• есть метрики и алерты;

• был нагрузочный тест после изменения размера пула;

• read-only и write-пулы различаются в метриках и логах.