I suppose the answer, like all db answers are..it depends :) My take on it is if the structure of "c" isn't likely to vary wildly over different entries and yo

I suppose the answer, like all db answers are..it depends :) My take on it is if the structure of "c" isn't likely to vary wildly over different entries and you have use cases that need queries like: get rows where c.ca == x and/or c.<some other field> == x ...and either the frequency or table size makes it unfeasible to scan through all entries, I'd opt for using a relational storage solution and chuck "c" into its own table with a foreign key entry in the original data structure. Otherwise a non-relational structure could suite it better, in which case you can still use Postgres or SQLServer or any other relational DBMS that supports json. I'd make the deciding factor in that case more about what do I forsee myself using for other use cases, e.g. if I'm already using a RDBMS for other models in the same app then just keep using it, but if not and all my data are arbitrary blobs of JSON then use any ol document store ¯\_(ツ)_/¯¯