Processing large data
Two different problems hide under "we have a lot of records", and they have two different answers. Writing a lot of data is about using bulk endpoints instead of a loop. Looking at a lot of data is about giving the browser a bounded slice to render.
Writing: one bulk call, not a thousand small ones
Most write endpoints accept an array as readily as a single object. Sending 500 records in one request instead of 500 requests is not a small optimisation — each request otherwise repeats the connection, the authentication, and the permission resolution, and you pay that overhead 500 times for nothing.
The bulk operations are documented in the API reference under the entity they belong to rather than in a section of their own, so look for them beside the single-record ones:
| What you are writing | Bulk operation |
|---|---|
| Records | PUT /record — update many records in one call |
| Modules | POST /module (create) and PUT /module (update) |
| Fields | PUT /field, and PUT /field/order/{id} to reorder a group |
| Labels | PUT /label, DELETE /label |
| Statuses | PUT /status/ |
| Users | PUT /user |
An SDK is the easier route if you are writing code: the same method takes one item or
many, and the *Chunked variants split an oversized batch for you and hand back a per-chunk result,
so one bad row does not cost you the whole run.
Pick a batch size and stay well under the request limit. There is no documented cap on items per call, but a request that is too large fails as a request, not as a friendly error. A few hundred records per call is a sane default; if you are also writing wide records with many custom fields, come down from there. Chunking with the SDK saves you doing this arithmetic.
Ask for a page when you read. GET /record without limit returns everything that matches,
which on a large module means a response nobody wanted. Pass offset and limit, and read the
total from the X-BoostSpace-FoundRecords header to know how far you have to go.
Deleting records and bulk writes are not available over MCP — its record tools work one record at a time. Bulk belongs to the API and the SDKs; give an agent the job of deciding what to change, and do the writing in code.
Looking at it: segments keep the browser honest
The database is comfortable with far more records than a browser is. Rendering tens of thousands of rows means holding all of them in memory and laying every one of them out, and past a certain size the interface stops feeling instant no matter how fast the backend answered.
That is what the Segmenter is for. A segment is a saved filter, so it hands the interface a bounded slice instead of the whole module — work through one slice, then move to the next. Above 70,000 records in a module Boost.space switches this on by itself, because past that point loading everything is the wrong default.
Cut the slices along a line that means something to the work rather than an arbitrary block of rows: one client, one region, one status, one month. A segment named after the job it serves stays useful, and it keeps the count small as a side effect.
Next
- Segmenter — creating and managing segments
- Filtering records — the filter grammar segments are built on
- API reference · SDKs
