You can always create your own. The ecto type is a map type not a json one. In the end ecto is not bound to any db at all and it makes way more sense to have types, which align well to elixir than ones that align well with a certain database.
@50kudos: ok, now perform jsonb search query on 500_000_000 rows in order to return 1_000_000 rows. Just few lettters, but they would be repeated way too often. It’s not really scalable option. Of course one thing like that would not force 100% server usage, but we should develop best solution and not only working solution.
@mischov: Unfortunately it’s probably not enough. You would need to do all is_* checks (except is_list and is_map) on all List elements and Map. Notice that somebody could type map with for example Atom as value. In such way encoding could not work as expected.
I honestly think it’s not different on query (even without indexing) because it’s only slower on write (It will not re-parse once store). Of course its binary size could take more bytes per row (even if we name it just d
I agree it’s not scalable, though I’m not sure that’s in term of space or time complexity.
Lets not going into old debate of best performance vs best development time or time to market or best maintainability etc.
Look, I’m not senior developer which would describe it properly. I believe this resource says enough:
Generally we should think about it especially when others (like in above linked article) have do it and explained why. However I agree that it should not be a longer discussion - I just wanted to suggest better alternative solution.