Fixing Person Properties Size Violation

1. The rejection is silent — the capture call succeeded; only the property update was discarded. Code keeps “updating” a profile that never changes.
2. It undercounts — the size check runs on a sample of person updates, so one warning implies many more rejected or at-risk updates for the same person.
3. It has a blast radius beyond properties — person properties are copied onto every event during ingestion, so a person near the limit also inflates their events toward the event size limit. If you see message_size_too_large for the same distinct IDs, it’s the same root cause (load fixing-message-size-too-large).

The three ways person state grows

Diagnosing means identifying which growth pattern you’re looking at — each has a different signature and a different fix:

These combine: a dynamically-keyed map of nested objects is the worst case and typically comes from “just sync the whole thing” integrations.

Diagnose

1. Query the warnings with posthog:execute-sql: SELECT timestamp, details FROM system.ingestion_warnings WHERE type = 'person_properties_size_violation' AND timestamp > now() - INTERVAL 7 DAY ORDER BY timestamp DESC LIMIT 20. The details JSON carries person_id and distinct_id. Remember distinct IDs are not persons — resolve them (posthog:persons-list filtered by distinct ID); the person’s properties are shared across all of their distinct IDs.
2. Profile the person’s properties against the three patterns:
   • Count the keys — hundreds+ means dynamic keying; look for the generated-name pattern.
   • Rank values by size (JSONExtractKeys(properties) + length() of each value via posthog:execute-sql, or eyeball the person page) — a few dominant keys means big payloads.
   • Open the large values — if a “reasonable” key holds a deep object tree, it’s the nesting pattern; note which branch grows.
3. Find the writer: grep the app code for the $set / $set_once / identify / setPersonProperties callsites producing that pattern — key-name templates for dynamic keying, sync jobs for big payloads, incremental merge-into-object logic for nesting.

Fix

The fix has two parts: a code change so the profile stops growing, and a one-time cleanup of the persons that are already inflated. Both are needed — the code change alone doesn’t unbreak affected persons (their updates keep failing until the stored blob is back under the limit), and cleanup without the code change just buys time until it reoccurs.

1. Code change — match the fix to the pattern

Person properties are for current state — bounded facts about the user (plan, role, counts, flags, last-N summaries):

• Dynamic keying → never template data into key names. Per-thing facts belong in events (query them with aggregations); if you truly need per-key state, keep a bounded map (last N, or counts per category).
• Big payloads → store the payload in your own storage and $set a reference (ID/URL) plus the few fields you actually filter on.
• Deep nesting → flatten: extract the handful of leaf fields analytics needs into top-level properties and stop syncing the container object.

2. One-time cleanup — propose $unset, don’t run it unprompted

$unset deletes person data irreversibly, and other things may depend on those properties — cohorts, feature flag conditions, insight filters. Treat it as a remediation the user decides on:

• Present the affected persons and the exact keys you propose to remove, with their sizes, and check whether any cohort/flag/filter references them before recommending deletion.
• Only after the user agrees, run it — as a throwaway one-off, never as code that ships in the application. Per key, posthog:persons-property-delete does the same job tool-side; for many keys/persons, a one-off script sending $unset:

• $unset takes top-level key names. For dynamic keying, generate the list from the key enumeration in Diagnose. For deep nesting, you can’t unset a nested path — unset the container and re-$set it with its slimmed value.
• Expect more affected persons than the warning samples show — the check is sampled.

Verify

1. After the cleanup, send a small $set (e.g. a profile_cleaned_at timestamp) and confirm it appears on the person — proof updates apply again.
2. Re-query system.ingestion_warnings with posthog:execute-sql (filter type = 'person_properties_size_violation', timestamp after your fix) — no new occurrences. Judge by absence of new warnings over a real usage window; historical counts don’t shrink.
3. If message_size_too_large was firing for the same persons, confirm it stopped too.

Related

• fixing-message-size-too-large.md — the event-side symptom of the same inflated-person root cause; fix the person properties first, then confirm events flow.