Database Schema for User Enrichment Data
Date: 2026-01-27
Status: accepted
Context
We need a database structure to store user enrichment data collected during onboarding and personalization flows.
Decision
We will store steps and options in the database using separate tables for steps, options, and user responses.
Our schema is defined in app/database/schemas/:
users.ts- User profile datasteps.ts- Onboarding stepsoptions.ts- Options for stepsuser-responses.ts- User's selected options
In terms of translations, we decided to store translation keys, instead of just text in our database to avoid duplicating the same steps in different languages and avoid re-inventing the wheel since we already store translations in the monolith.
Also, this approach enforces valid step keys and values when we store user responses to the database, enabling reliable queries and analytics. We can answer questions like "how many users selected answer X" or identify the most popular option combinations across different onboarding flows.
Consequences
Adding or changing schemas requires a database migration instead of just editing code. This ensures consistency but adds a step to the process.
We store translation keys instead of translated text. This means our API must translate keys on every request based on the x-statista-platform header.