As always, it depends on the needs. The embedded schema implementation at least uses the pre-existing Ecto niceties and you can decide what structure makes the most sense for your real business requirements.
Ah yes, good old hashmapwithindifferentaccess, unfortunately we have to contend with erlang’s map implementation in C, but hey, you can always convert the list of tuples to gb_trees 
Yes, exactly why the schema should just be a way to store the data in the DB, and you’d write a module for the real data structure that hides these implementation details. Like MapSet is just opaque Map under the hood.
No, that’s a different thing (and not a Ruby one AFAIR). Indifferent access means that accessing may be done using either atoms or binaries (indifferent) without having to worry how the hashmap was created. What I refer to is LMGTFM… this:
I think it was introduced in 2.0 some years ago and I even recall I used it in similar problem and guy called me on that during code review, until I showed that it’s a documented feature already
how quick it is, for that data type is relative to its size (or rather length), because you need to scan it whole or until you will find :b, if those “keys” are unique.
to find it really quickly, you probably would need to use a MapSet or a Map, i guess?
EDIT: or a pattern match if you know its length? but i am not sure how fast it is.
Very much depends on exact restrictions.
If keys can not be repeated, just do plain map (jsonb).
If you need to store exact value type, serialize it and store as binary blob
:erlang.term_to_binary([a: 5, b: "five", c: :five])
In my opinion the best way to solve issues like this is to first decide how you would represent it in the database if you weren’t using Ecto. Keep in mind Ecto is just defining a mapping between Elixir and your persistence layer. If you don’t know what you want to do in your persistence layer you don’t know what you want to do in Ecto.
Keys are unique but their order is important. I’d love to just serialise the Map and be done but in Elixir (Erlang/OTP) that does not guarantee that the order will be preserved.
It needs to fit into an existing JSON structure. While it doesn’t really need to be human-readable, it would still be nice to have it as an array of JSON “objects” along with everything else. But yes, I guess this could be doable this way, although this would be the only unreadable JSON part then.
That’s how I decided I’d prefer to have it but I ran into limitations. I did implement it as a List of single-element Maps but didn’t like the complexity and ineffectiveness of handling those. Still - after reading the comments and realising (thank you @ruslandoga) that I don’t have to reinvent the wheel this seems like the “least bad” approach, short of custom types
if you want to encode it to native JSON types, 1 to 1 - it’s not possible.
if you are flexible, you can encode it into JSON array of two element arrays.
if you want to encode anything more complex - like “ordered sets” or “indexed lists” , you need to:
open question remains: what’s the cost of integrating it into Ecto?
I would go for two maps handled by a homemade Ecto.Type:
When you want to access the key/value pairs in order, just use the second map.
Those two maps can also be wrapped in a single map, no need for two DB table columns either.