Why not keep every user field in one users table?

Because fields about a user do not all have the same risk. Login credentials, public biography text and interface settings need different readers, writers, retention rules and deletion behaviour. A single table makes accidental exposure and lifecycle coupling more likely, especially when exporting, anonymising, resetting preferences or showing profile information to other users.

How do I decide whether a field is identity, profile or preference data?

Ask what the field does. If it proves or protects account ownership, treat it as identity. If it describes the person or account inside the product, treat it as profile. If it changes how the product behaves for that user, treat it as preference. Some fields depend on usage, so classify by behaviour, not name.

Are preferences always low-risk data?

No. Preferences are often less sensitive because they can be recreated and usually do not prove identity, but context matters. Notification settings, locale, accessibility choices or saved filters can reveal personal information or work patterns. They still need appropriate access control, but they usually have looser durability requirements than authentication records.

Where should authentication provider IDs and password hashes live?

They belong in the identity layer, usually in the authentication system or tables protected with the strongest access controls. Application profile code should not need direct access to password hashes, MFA state or provider identifiers except through narrowly defined account-management paths. Keeping them separate reduces accidental leakage from product-facing queries.

Profiles, Preferences & User Data

Profiles, preferences and user data are separate categories inside a user system: identity proves account ownership, profile describes the user in the product, and preferences customise behaviour. Treating them separately lets engineers apply the right access controls, retention rules, audit requirements and deletion behaviour to each kind of record.

The problem is that “user” sounds like one object, but the fields attached to a user have very different meanings. An email used for login, a public display name and a dark-mode setting should not have the same privacy boundary or lifecycle. If they live in one undifferentiated record, simple product changes can accidentally expose credentials, make deletion unsafe, or turn harmless settings into regulated personal data problems.

A practical design splits the account into linked records. Identity data is owned by the authentication boundary and contains login identifiers, credential state, provider links, MFA configuration and account status. Profile data is owned by the product and contains things other people or features may display. Preference data is owned by the experience layer and stores choices such as locale, notifications, onboarding progress, saved filters or layout state.

The trade-off is extra modelling and more explicit joins, policies and migration work. You have to decide field by field which box it belongs in, and the honest answer can depend on the product. A phone number may be identity data if used for login, profile data if shown to team members, or preference-adjacent if used only for notification routing. The benefit is that this ambiguity is handled deliberately rather than hidden.

Engineers meet this split when designing user tables, auth integrations, row-level security rules, account deletion flows, data exports and cache behaviour. Identity tends to be minimal, durable, audited and tightly restricted. Profile data needs visibility rules that match the feature. Preferences can often be cached, reset, overwritten or recreated without threatening account ownership. The common mistake is optimising for a convenient users table instead of matching data to its actual promise.

Go deeper

User SystemsProfiles, Preferences & User DataSplit the user record into identity, profile and preference data, and say why the three have different durability and privacy rules.Open the lesson

Common questions

Why not keep every user field in one users table?: Because fields about a user do not all have the same risk. Login credentials, public biography text and interface settings need different readers, writers, retention rules and deletion behaviour. A single table makes accidental exposure and lifecycle coupling more likely, especially when exporting, anonymising, resetting preferences or showing profile information to other users.
How do I decide whether a field is identity, profile or preference data?: Ask what the field does. If it proves or protects account ownership, treat it as identity. If it describes the person or account inside the product, treat it as profile. If it changes how the product behaves for that user, treat it as preference. Some fields depend on usage, so classify by behaviour, not name.
Are preferences always low-risk data?: No. Preferences are often less sensitive because they can be recreated and usually do not prove identity, but context matters. Notification settings, locale, accessibility choices or saved filters can reveal personal information or work patterns. They still need appropriate access control, but they usually have looser durability requirements than authentication records.
Where should authentication provider IDs and password hashes live?: They belong in the identity layer, usually in the authentication system or tables protected with the strongest access controls. Application profile code should not need direct access to password hashes, MFA state or provider identifiers except through narrowly defined account-management paths. Keeping them separate reduces accidental leakage from product-facing queries.

Every term