Consider what I’d call “option 3B”: store the state in a database table that has a BLOB column with an :erlang.term_to_binary in it.

This avoids the extra complexity of serializing/deserializing into other shapes.

It does make the contents of the state very opaque to DB queries, since doing binary-to-term in SQL would be quite challenging.

you need to keep in mind that it gonna be a migration that needs to, retrieve data from the db, transform it in elixir, write back to the db. it’s preferable for your migration to do all the work as just sql statements, sometimes you can’t avoid the back and forth but in this particular case you could avoid it by just making it a unstructured column that the db knowrs how to handle.

so, when you do %MyStruct{field_a: 1, field_b: 2} you’re actually calling a function MyStruct.__struct__(field_a: 1, field_b: 2), this function is defined when you do defstruct .... This function is the thing that ensures that the output map has all the fields of the struct and only those fields and no other stuff.
so if the struct definition changes between when you do term_to_ binary/1 and binary_to_term/1 you gonna end up with a map without the guarantees of the __struct__/1 function call. you can test this on iex:

defmodule A, do: defstruct [:a, :b]
bin = :erlang.term_to_binary(%A{})
defmodule A, do: defstruct [:a, :c]
:erlang.binary_to_term(bin)

the risk of doing that is that all function that you pattern match on %MyStruct{} gonna pass, but the struct can end up not having the shape that you expect.

if there is a need to use binary_to_term/1 with structs, I strongly suggest using Map.from_struct/1 and struct/2 functions to ensure at least a few of the guarantees of what you expect from a struct are kept.

it’s off-topic but I see migrations as db “book keeper”, any relevant change or important operation I like to keep it as migration for historical purposes. in case is something to be executed manually, i’d just add the timestamp of the migration to the schema_migrations table and that’s it. but i don’t think this applies here

Adding my thoughts on this to help OP and future readers out. I have done the :erlang.term_to_binary cast into db column approach for storing game state before and it works lovely. You can even :zlib.zip/:zlib.unzip too, if you like. To the three things you’ve pointed out:

1. For my case at least, this isn’t an issue. YMMV, but I think it’s likely that, like OP, many people will be in an “I just need to get this working” state, so they won’t care about this. If you do ever need it, you can extract the fields you need as separate columns*. Then you can use a migration, written in Elixir, to migrate existing data. You even have options here too - you can do a “bulk” update where you change all the records at first app boot up or you can do a “live update” where you do this migration when records are accessed/written.

* Another possibility is reporting on the metric you’re interested in elsewhere. For example, when making a clone of the game Boggle, I stored boards and user’s submitted words as erlang binaries in blob columns. I wanted to do reporting on the number of “globally new” words found by users every time they finished a game. Rather than changing the structure of existing, working tables, I just did the reporting to Prometheus. This is a highly specific to me example, but I wanted to share other ways I think are valid to work around this issue.

2. It will certainly not be as easy as UPDATE SET field WHERE clause, but it can be done. How one does this depends on a lot (size of records/tables/concurrent users). When building a small game, chances are there are few users and hence large chunks of time you can afford to have an inconsistent DB. This is highly dependent on all of the factors mentioned above, because if your records are small, you have few users and few games, such a migration script and its associated inconsistency might last a few seconds on the extremely long side. Even if this isn’t the case, there are ways around that - they aren’t easy, but it is possible.

3. I’d like to hear more about this if you can give an example. I’m fairly new to Elixir and my understanding is that structs are basically just maps with syntactic sugar.

I think you’re probably right in the general case, but I think in OP’s case - a card game with likely single to double digit users and low data volume - this is unlikely to be an issue and certainly I wouldn’t say “there is no way” to do this. There are just some risks and if folks understand those risks, then they can find ways to work around them in the interim until they feel like moving to an approach that more closely resembles what you’re describing.