Error: Too many clients already. The remaining connection slots are reserved for non-replication superuser connections. @rahul1, @reshma We are currently loading patient data from (EHR systems such as Epic and Cerner. A single patient can have multiple FHIR resources, and each resource may contain hundreds of records, such as observations or document references. When saving this data into the Medplum database, we store the EHR ID of each resource in the identifier field. This issue was previously discussed in Medplum Issue #2362. We iterate over FHIR resources and make changes to the ID references before saving in the DB. The current issue we're facing occurs when loading patient data. We are encountering the following error: Too many clients already. The remaining connection slots are reserved for non-replication superuser connections. Logs: "Database connections numbers - max: 100, total: 76, idle: 45, waiting: 33, expired: 0" {"level":"ERROR","timestamp":"2025-01-27T09:28:14.299Z","msg":"Database error","error":"sorry, too many clients already","stack":"error: sorry, too many clients already at SqlBuilder.execute packages\\server\\src\\fhir\\sql.ts:419:22) at SelectQuery.execute packages\\server\\src\\fhir\\sql.ts:619:13) at getSearchEntries packages\\server\\src\\fhir\\search.ts:294:16) at searchImpl packages\\server\\src\\fhir\\search.ts:119:42) at Repository.search packages\\server\\src\\fhir\\repo.ts:1145:22) at Repository.searchOne packages\\fhir-router\\src\\repo.ts:190:20)

Sounds like you've maxed out available pg connections. How many connections are opened per instance of the server is [configurable](https://github.com/medplum/medplum/blob/363379f85805b9c3ac05fdf9a7299a132366ba9c/packages/server/src/config.ts#L116), defaulting to [100](https://github.com/medplum/medplum/blob/363379f85805b9c3ac05fdf9a7299a132366ba9c/packages/server/src/database.ts#L52) if not set. Depending on how you are running postgres, you can potentially increase the maximum available.

Hi @Amarjeet - yes, @nathan-watkins-unityai is correct! Thanks @nathan-watkins-unityai !

Thanks, @nathan-watkins-unityai @cody, for the clarification. If importing a single patient requires 100 connections, how would it scale when handling many concurrent patient imports? Would we hit the connection limit quickly, and if so, what would be the recommended approach to mitigate this? Would optimizing connections opened with getSystemRepo() per patient import help in this scenario? Please let me know if there is a better solution for scalability.

(Just to be clear, I'm also a self-hosted medplum user and not on the medplum team) Medplum uses [connection pools](https://node-postgres.com/features/pooling). You can run these sql commands to get an idea of what your pg server is capable of.

SHOW max_connections;
SHOW superuser_reserved_connections;

If your pg instance is only used for medplum and you are only running 1 replica of the server, you could start with

max_connections - superuser_reserved_connections - X

where

X

is a reasonable buffer, like 5-10. Medplum scales fine, but your pg server size could end up being a bottleneck depending on your throughput. Probably not though. Try tuning the

maxConnections

first.

> If importing a single patient requires 100 connections, how would it scale when handling many concurrent patient imports? It is unlikely that importing a single patient used 100 connections. Maybe 1-2 (one for user, one for system). Maybe more if executing multiple HTTP requests simultaneously. My interpretation of the error you encountered is not that Medplum required 100 connections, but rather that the simultaneous number of connections exceeded the capacity. > how would it scale when handling many concurrent patient imports? The main hosted Medplum cluster (api.medplum.com) uses AWS Aurora, one main writer, and multiple reader instances. The main writer hovers between 10-30 open connections at anytime. That is enough to handle thousands+ FHIR interactions per second, when using a well tuned database + well tuned servers.

@nathan-watkins-unityai @cody , thanks for the update. We are importing patient data from EHR systems like Epic and Cerner. Each patient has multiple FHIR resources, and each resource can contain hundreds of records (e.g., observations or document references). When saving this data to Medplum, we store the EHR ID in the identifier field. During import, we process FHIR resources, update ID references, and then save them to the database. Although connection pooling is enabled and should limit usage to 2-3 connections per import, we’re seeing 50-60 connections being used. Could this be due to multiple concurrent FHIR transactions or long-running queries holding connections for too long? Would it help to ensure connections are released properly after each transaction? or adjusting connection timeouts help prevent connection accumulation?