Realtime Database 250KB write limit: does it apply per path in a multi-path update or to the whole payload

The Short Answer

The write size limit applies to the combined serialized payload of the entire request. In a multi-path update() call, the limit is checked against the total size of the update map, not against each individual path value separately.

Technical Behavior and Constraints

Because a multi-path update is processed as a single atomic operation, the database engine evaluates the entire request packet. If the aggregate size of all paths and values in your update exceeds the threshold, the operation will fail.

Atomicity and Failure

If the combined payload exceeds the limit, the entire update fails atomically. No partial updates are applied to the database. From a client-side perspective, this typically manifests as a failed promise or an error callback, often returning a generic internal server error or a permission-related failure depending on the SDK version and the specific point of rejection.

SDK and Plan Consistency

Variable	Behavior
SDK Type	Consistent across Client SDKs and the Admin SDK; the limit is enforced server-side.
Pricing Plan	The limit is a technical engine constraint and does not differ between Spark and Blaze plans.

Practical Implementation and Risks

If you find your fan-out logic regularly hitting this ceiling, you face a trade-off between atomicity and capacity:

• Splitting Writes: Dividing one large update() into several smaller calls avoids the payload limit but sacrifices atomicity. If the connection drops mid-sequence, your data layer will be in an inconsistent state (partial fan-out).
• Data Denormalization: If the payload is too large, it often indicates that too much data is being duplicated across paths. Consider storing a unique ID in the fan-out locations and keeping the heavy payload in a single source-of-truth node.

Verification Steps

To verify your specific data shapes against this limit, you can use these scoped tests:

1. Aggregate Test: Create an update map with 10 paths, each containing ~30KB of data. If the total exceeds the limit, the entire operation should fail.
2. Single Path Test: Attempt to write a single value exceeding the limit to a single path to confirm the baseline failure threshold.

Diagnostic Detail Needed: To provide a more specific recommendation on splitting writes, are you using a Cloud Function for this fan-out, or is this happening directly on the client side?