Deciding whether to use column versions or new rows in GCP Bigtable

Let’s say I want to store a snapshot of a User’s Settings every time they make a change. These snapshots would allow the User to see a history of the changes they made to their settings.

Would it be better to write to a new row for every change (Method A) or to write to the same row for every change (Method B)? Am I missing any pros/cons to either method?

The following examples show a User(userId123) making the following changes:

1. Turn notifications ON
2. Turn notifications OFF
3. Turn notifications ON

---

Method A:

The key would be the userId + timestamp so it writes to a new row every time.
Queries would scan by row prefix (userId) and get multiple rows to show history

pros:

• since every change is stored in a new row, it will never hit the 256mb row size limitation

cons:

• requires a scan by prefix for queries (I assume this is slower than looking up by rowkey?)

---

Method B:

The key would just be the userId and would write to the same row every time creating a new column version.
Queries would lookup by row key (userId) and get a single row with multiple column versions for history

pros:

• queries can be looked up directly by row key (I assume this is faster than scanning by row prefix?)
• version based garbage collection can be used to only store last X number of versions

cons:

• 256mb row size limitation (hitting this does not seem likely unless changes are made very frequently)

This scenario would lend itself better to storing the changes in one row with versions. You could even set up garbage collection rules to delete any changes that are more than one year old as you mentioned.

One thing to help optimize this method further is if you only need the latest data or latest 5 changes in some scenarios you could perform a query that would filter to give only 5 versions and safe on network costs.