fix: apply configured pool size to core database (#23322)

## Context

`PG_POOL_MAX_CONNECTIONS` is the server setting for the maximum number
of PostgreSQL clients in a connection pool. The workspace primary and
replica data sources already apply this setting, but the core TypeORM
data source did not.

Without an explicit `poolSize`, `node-postgres` uses its default limit
of 10. As a result, deployments configured with a larger pool still kept
the core pool at 10 connections per server process.

During bursts of core database work, requests could therefore wait for a
local pool connection even when PostgreSQL itself still had available
capacity. That acquisition queue adds latency before the query starts,
so database-level utilization alone does not reveal the bottleneck.

## What changes

The core data source now applies:

```ts
poolSize: Number(process.env.PG_POOL_MAX_CONNECTIONS ?? 10)
```

This makes the core data source consistent with the workspace data
sources and with the documented meaning of `PG_POOL_MAX_CONNECTIONS`.

## Expected impact

Deployments that configure a value above 10 can use that capacity for
core database operations instead of queueing behind the driver's default
limit. This targets short acquisition spikes affecting operations backed
by the core database.

The pool remains lazy, so this changes the maximum number of connections
available to each process, it does not eagerly open every configured
connection.

## Safety

- Deployments without `PG_POOL_MAX_CONNECTIONS` keep the previous limit
of 10.
- Query behavior, transaction behavior, and timeouts are unchanged.
- Workspace pool configuration is unchanged.
- Operators remain responsible for choosing a value compatible with
their total PostgreSQL connection budget and maximum server replica
count.

## Scope

This removes an unintended local connection-pool bottleneck. It does not
address the source of synchronized database bursts, which should be
handled separately by reducing unnecessary work.

## Testing

Added a regression test that loads the core data source with
`PG_POOL_MAX_CONNECTIONS=40` and verifies that TypeORM receives
`poolSize: 40`.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/23322?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
This commit is contained in:
Weiko
2026-07-27 10:58:41 +02:00
committed by GitHub
parent 42c598a33a
commit a96dc335ab
2 changed files with 22 additions and 0 deletions
@@ -0,0 +1,21 @@
describe('typeORMCoreModuleOptions', () => {
const originalPoolMaxConnections = process.env.PG_POOL_MAX_CONNECTIONS;
afterEach(() => {
if (originalPoolMaxConnections === undefined) {
delete process.env.PG_POOL_MAX_CONNECTIONS;
} else {
process.env.PG_POOL_MAX_CONNECTIONS = originalPoolMaxConnections;
}
jest.resetModules();
});
it('uses the configured maximum pool size', async () => {
process.env.PG_POOL_MAX_CONNECTIONS = '40';
const { typeORMCoreModuleOptions } =
await import('src/database/typeorm/core/core.datasource');
expect(typeORMCoreModuleOptions.poolSize).toBe(40);
});
});
@@ -54,6 +54,7 @@ export const typeORMCoreModuleOptions: TypeOrmModuleOptions = {
],
synchronize: false,
migrationsRun: false,
poolSize: Number(process.env.PG_POOL_MAX_CONNECTIONS ?? 10),
migrationsTableName: '_typeorm_migrations',
metadataTableName: '_typeorm_generated_columns_and_materialized_views',
// The TypeORM migration system is frozen — historical migrations live in