Scaling the user directory itself.

The pain starts when the user store stops being a table and becomes a system. A few million rows in Postgres works fine until you need sub-100ms authentication globally, and then everything breaks at once: profile lookups slow, admin search across users times out, bulk operations lock tables, and peak events (Black Friday, a product drop, a streaming TV moment) produce 50 to 100x baseline login traffic the auth path was never provisioned for. Login is uncacheable and on the critical path of every session, so unlike content you cannot CDN your way out.

The evaluation question enterprises land on is whether the vendor can prove peak-load behavior, not average. Teams that have been burned ask for rate-limit specifics (per-endpoint, per-tenant), token issuance throughput, and what degrades first under load. Rate limits are a notorious hidden constraint: a platform that caps management-API calls at a few hundred per second turns a nightly CRM sync or a mass credential reset after a breach into a days-long job.

Schema flexibility is the quieter scaling problem. Consumer profiles are not static; loyalty tier, marketing preferences, device history, KYC status, and per-brand consents all accrete. Rigid schemas force data into a parallel database, which immediately recreates the fragmentation CIAM was supposed to solve. So buyers now ask: custom attributes, searchable or not, indexed how, queryable at what latency, and who can read and write them at the API level. See CIAM at high scale and multi-region CIAM.