# Diagnose pressure from many small inserts

Coordinator DB does not report a physical-parts maintenance condition or require part merging. When an importer sends many small writes, investigate request overhead, admission failures, locks and the actual SQL error instead of applying an unrelated maintenance command.

## Group work deliberately

Use one multi-row VALUES statement or one formatted input statement for rows belonging to a batch. A successful response follows statement completion; there is no asynchronous INSERT queue. Measure a few batch sizes with the same representative data and compare duration and peak memory.

A larger batch should still fit the intended transaction and recovery boundary. Do not combine unrelated work merely to reduce request count. Keep a stable batch or event identifier so an interrupted response can be reconciled before retrying.

## Read the reported limit

HTTP 503 can signal admission or locking failures. SQL request limits separately bound time, accounted memory, returned rows and response bytes. Raising `max_connections` cannot correct malformed input or a schema constraint error.

Use `system.query_log` to inspect completed events and `system.processes` for active work. Apply an external retry policy only to failures it can safely classify, and avoid replaying an ambiguous write unconditionally.

See [batch inserts](https://coordinatordb.com/docs/concepts/features/operations/insert/bulkinserts), [server admission](https://coordinatordb.com/docs/reference/settings/server-settings/settings/max) and [HTTP errors](https://coordinatordb.com/docs/concepts/features/interfaces/http).