03.01 · Concept · Free
Profiles, Preferences & User Data
Split the user record into identity, profile and preference data, and say why the three have different durability and privacy rules.
Curated for this lesson1/3
User Data & Lifecycle
Advanced Row Level Security (RLS) Policies // Authorization Deep Dive
RLS authorization is directly relevant to privacy boundaries around identity, profile, and preference records.
User data should be separated into identity, profile and preference records because each category has different security, visibility and lifecycle requirements. Login and account state need strict protection, profile fields need explicit sharing rules, and product settings can usually be cached, reset or removed without affecting account ownership.
What this lesson answers
- what belongs in identity versus profile data
- how should user preferences be stored separately
- why not keep all user fields together
Notes
A user record is not one kind of data. Identity data proves who the user is: login identifiers, password hashes, OAuth provider IDs, MFA settings, and account status. Profile data describes the person inside your product: display name, avatar, bio, organization, role description, or public contact details. Preference data describes how the product should behave for that user: theme, notification settings, locale, onboarding state, saved filters, and layout choices.
The mental model is three boxes with different promises. Identity is security-critical and should be minimal, tightly protected, audited, and durable for as long as the account exists. Profile is product-facing and may be public, private, or shared depending on the feature, so it needs clear visibility rules. Preferences are usually low-risk and easy to recreate, so they can change often, be cached aggressively, and sometimes be deleted without breaking account ownership.
A common misconception is that everything about a user belongs in one users table because it is convenient. That is wrong because convenience couples unrelated privacy and lifecycle rules. Deleting a preference should not risk deleting login credentials. Showing a public profile should not expose email or MFA state. Exporting personal data, anonymizing an account, or complying with retention rules becomes much harder when identity, profile, and preferences are mixed together.
After this lesson, you should be able to look at any user-related field and ask three questions: does this prove identity, describe the user, or customize the experience? You should also be able to explain who may read or change it, how long it must survive, and what happens when the user deletes, resets, or anonymizes their account.
Common questions
- What is the difference between identity, profile and preference data?
- Identity data is used to authenticate and secure the account, such as login identifiers, credential state and MFA configuration. Profile data describes the user inside the product, such as name, avatar or organisation. Preference data controls product behaviour for that user, such as theme, notification choices, locale or saved filters.
- Why is one users table a bad default?
- A single table ties together fields with different privacy and durability requirements. Public profile display can accidentally sit beside sensitive account state, while simple preference changes become coupled to login data. That makes access control, deletion, export, anonymisation and retention harder to reason about and harder to test.
- How do durability rules differ across user data types?
- Identity data should normally survive for the life of the account and be changed carefully. Profile data may be edited, hidden or anonymised depending on product rules. Preferences are usually less durable: they can often be reset, recreated, cached or deleted without damaging authentication or account ownership.
Short definition: what is Profiles, Preferences & User Data?