mediumDesignConceptMidSenior
You are building a user-profile service. Key-value store or document database: what decides it?
It is decided by everything besides fetching a profile by user id. If every read is by id and every write replaces the whole profile, a key-value store is enough. Login by email, unique emails and field-level updates push towards a document database, or towards index items you maintain yourself.
4 min readUpdated 2026-10-10
Answer
Short answer
The deciding factor is what you need besides "get profile by user id". If that is the only read and writes replace the whole profile, a key-value store is enough. Once you need login by email, unique emails, single-field updates or search by field, a document database does that work for you. The alternative is plain key-value storage plus index items you write and keep consistent yourself.
Was this answer helpful?
Likely follow-ups
- A user changes their email address. Walk through every write, and say what happens if the second one fails.
- The profile now carries a login history that grows forever. Where does it live?
- Support staff need to search by partial name and phone number. Which store answers that, and how does it stay current?
- Two services update the same profile at the same moment. Which update is lost in your design, and how do you prevent it?
Related questions
- How do you choose between a document store, a key-value store, a wide-column store and a graph database for a new service?hardAlso on nosql5 min
- How does the reserve figure your systems produce end up changing next year's rates, and where does that loop break?hardAlso on data-modelling6 min
- What is a loss development triangle, and what does the actuary need from your claims system that reporting does not?hardAlso on data-modelling5 min
- We sell to trade customers who each negotiate their own prices, and those prices change. Design the schema.hardAlso on data-modelling5 min