What if, the newly added JSON datatype in mysql is a way to provide mysql with no-sql-like capabilities.
I mean, some would prefer no-sql cuz they beleive that the tables schema will evolve a lot.
An extra column in mysql table with json datatype called "custom_fields" would do the trick.
What do u think ?

I use an extra column and store an json array for data that doesn't need to be normalised, or it has limited usage like a session handler.

Beyond that, I haven't had a need "yet" to use the mysql-json functions for retrieving data like a nosql db.

Mongodb and other nosql like storeage is good if you mostly fetch complete objects, just like a json column but when you also need the change data in the json.

For example, you have an array in the document you need to append to or delete from.

With a json you either need to read it out, update and store back in or some syntax to change just part of the json, like mssql’s xml datatype.

So the choice of database should be made based on what you need to save and how you will access and update it.

Sql is by far the most flexible and if you want to use a single db I would recommend some sql. Its the most jack of all trades.

But if you have high throughput needs or specific access patterns and need to scale I would make sure to check out a multi db solution storing different data in different database types.

Just make sure to learn enough about each first ;)

We built one in pure mongodb and some things just was a pain to get to work.

@Voxera seriously bro, i always beleived that no-sql is for developpers that are bad in "data-structure" skills.
Ok i k now abt agile dev and evolving structure, but it is so easy to add a column, indexing ir and add a field in the related model/activerecord.

I always roll with the eyes if an customer wants mysql or an software that requires it.

@stop I mean, Mariadb is quite nice and has most of mysql features.

@Lor-inc it depends of the client, big clients work with GCP or AWS but small ones have a mutualized hosting at some local cheap hosted with php/mysql

@Lor-inc its the same. Our customers have a high probability that they want to store extremly large amounts of data, which cant be efficiently backed up.

@devapsarl nosql can for some work loads or updates scale much better than most or all sql.

The problem is that this is achieved via sacrifices.

Less locking, more loose connections, usually no or expensive transactions outside of an objects and so on.

This makes sharding and replication and parallel processing very easy with very little overhead.

If you also go with eventual consistency you can handles spikes.

But this means that you have to understand how your data works and where you need what.

And using multiple different databases can allow for best performance for each type of data.

For a small site or home project its mostly a matter of taste, your unlikely to face any performance problems anyway ;)