A city's citizen-profile service keeps adding optional attributes for new programs, and rigid relational migrations delay each release. Which approach best fits this evolving, high-scale profile data?
Select an answer to reveal the explanation.
Short Explanation
Think of citizen profiles like a filing cabinet that keeps growing new folders—locking the drawer shape every week just slows the city down. NoSQL shines when attributes keep changing and you still need to scale. Let the model bend so programs can ship without a schema fire drill.
Full Explanation
Citizen profile services in municipal programs routinely gain optional attributes as new benefits, eligibility flags, and contact preferences appear. A flexible NoSQL document (or similarly schema-flexible) model stores those semi-structured records so new fields can land without blocking every release behind a relational migration. That approach matches evolving, high-scale profile data where attribute churn is expected and horizontal growth matters. Normalizing every new attribute into additional relational tables before each ship recreates the migration bottleneck the city is trying to escape and slows program launches. Freezing the schema permanently and rejecting unknown fields protects purity at the expense of civic agility; residents then wait while engineering renegotiates columns. Requiring a full warehouse rebuild for each optional field confuses analytical remodel cost with operational profile serving and is disproportionate for sparse program-specific attributes. Exam caveat: flexible NoSQL fits evolving documents; it is not a license to abandon governance—define required keys, validation at the edge, and retention even when the physical schema bends. Operational check: add one new optional profile attribute in a lower environment without a DDL migration, write and read a sample citizen document with and without that field, and confirm the portal release is not gated on a multi-table alter.