# Question on updating data structures of stable variables in Motoko

**URL:** <https://forum.dfinity.org/t/question-on-updating-data-structures-of-stable-variables-in-motoko/11758>\
**Category:** Developers\
**Created:** [March 29, 2022, 12:40am UTC](https://forum.dfinity.org/t/question-on-updating-data-structures-of-stable-variables-in-motoko/11758 "2022-03-29T00:40:31Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![chenyan](https://avatars.discourse-cdn.com/v4/letter/c/35a633/32.png) [@chenyan](https://forum.dfinity.org/u/chenyan)\
**Post date:** [March 29, 2022, 6:52pm UTC](https://forum.dfinity.org/t/question-on-updating-data-structures-of-stable-variables-in-motoko/11758/11 "2022-03-29T18:52:51Z")

</div>

Yes, it is unfortunate that you cannot add a new field (doesn’t matter if it’s optional or not) to a stable record, because the stable typing follows the Motoko subtyping not the Candid subtyping rule.

To add a new field, you will need to define a new stable variable and copy the old data over to the new stable var. This come be done either through the `postupgrade` logic or in the initialization if the data structure is simple enough. For example,

```auto
stable var old_record = { a = 42; };
stable var new_record = { a = old_record.a; b = "default_value_for_new_field" };

```

This is not ideal as you point out: 1) it doubles the memory usage; 2) it’s simply not convenient, as adding a new optional field is very common.

We choose this approach, because it’s the least effort at the moment to prevent data loss during upgrade statically. In the long term, we probably need to design a new serialization format for stable variables to fit the use cases better.

---

_[View the full topic](https://forum.dfinity.org/t/question-on-updating-data-structures-of-stable-variables-in-motoko/11758)._