I’ve been using text fields in MySQL to store json encoded associative arrays (sometimes to the degree of a ‘junk drawer’). I use this approach for data that normally wouldn’t be used in queries but would be used in reporting or details of a transaction. This provides a lot of flexibility regarding additional fields of data without having to redefine a scheme every time the application’s storage requirements change (this allows many versions of my code to use the same schemas). As Andraz pointed out this also is great for custom fields (which I use extensively for client projects – where moving targets are a fact of life).

The ability to have native json support in MySQL means I can now refine the queries that occasionally need to include these fields (I’ve been using special post-select filtering when necessary). I’ve used PostgreSQL’s native json support and had recently migrated two projects to Postgres in order to take advantage of the native json support.

Another use for this is flexible logging of user requests. Every one of my ajax requests sends data via json and I store every request for auditing purposes. With native json support it will be much easier to report on these requests without having to unwind every text field every time I’m reporting specific information.

Native json support also lets MySQL (as well as Postgres) play both sides in the SQL vs No SQL game. I don’t have a true need for No SQL very often but I’ll no longer need to compromise when I do now that MySQL supports json.

Regarding Camilo’s concerns, every datatype can be abused (such as what I’ve done by using text fields as pseudo-json). Not implementing useful features because some may not use them as designed is no reason to invalidate their necessity. Json data is pervasive throughout intranet & internet applications. Native support for json is a welcome change for me (and I assume many others).