group fields storage

I think due to this limitation I will not be able to use some of your add-ons if I want to write query on JSON file.
addon like CB Code Field

Great and Congratulations !!!

Instead of resolving this issue now I can see you have restricted field group functionality for MySQL 5.6 and lesser version (earlier it working for me). This is not a customer centric approach.

Now I am getting the following error message
"Unsupported database for Field Group searching and optimal storage. Please update to MySQL 5.7.8+ and ensure Community Builder is up to date."

CB Field Groups is not restricted to MYSQL 5.7. You can use it on MYSQL 5.6. Using it on MYSQL 5.6 means it will use a TEXT column instead of a JSON column, which is slightly less efficient storage (not a huge deal, but can be if you use a lot of them). The main feature disabled on MYSQL 5.6 is the inability to search field groups. The reason for this is the MYSQL JSON functions do not exist in MYSQL 5.6.

If you need field groups to be searchable then I'm sorry it will not work on MYSQL 5.6. There is no efficient way to search such data without MYSQL 5.7 JSON functions. If all you need is its ability to store and display groups of fields then it will work perfectly fine on MYSQL 5.6.

As for VPS hosting it's not expensive like it used to be. You can get a $2.50/mo cloud VPS from Vultr for example. DigitalOcean has cloud VPS for as little as $5/mo. There's quite a bit more with same pricing (e.g. Linode). As for shared hosting I've no idea; maybe A2 Hosting or SiteGround offers MYSQL 5.7, but usually the reason shared hosts don't is they won't update their OS and won't update cPanel. MYSQL 5.6 is end of life so they won't have much of a choice come 2021 when extended support ends.

Basically, You don't want to be convinced. If you asking the client to use JSON field as a text then I am not sure how we are going to use it efficiently.
Joomlaplis community builder is just a single table application everything stored in just a single table (%_comprofiler) so you should not think much about performance. I work on Oracle E-business suite where hundred of tables are connected and they works absolutely fine.

I am not agree with the suggestion you provided. Could you please let me know what will be the additional cost to make the changes as per my requirement.

Basically, You don't want to be convinced. If you asking the client to use JSON field as a text then I am not sure how we are going to use it efficiently.

We're not rewriting the plugin to use a different storage method, sorry. There is no need to for a EOL SQL version. A TEXT column storage wise will be fine. It will not be for searching, which is why searching is disabled if it's not a JSON column.

Joomlaplis community builder is just a single table application everything stored in just a single table (%_comprofiler) so you should not think much about performance.

Storage performance is important because it's a single table. There are limits to row storage sizes and index pointers. JSON columns are stored more efficiently for JSON data. In addition to that and more importantly MYSQL JSON functions do not exist in MYSQL 5.6 and do not work against non-JSON data, which the JSON column guarantees.

I work on Oracle E-business suite where hundred of tables are connected and they works absolutely fine.

That's wonderful for what you're doing, but isn't how our fields are designed. We've no need to store them separately and force a join on every user row query. We will be exploring different storage methods in the future for all fields in general, but at this time there are no plans to make any such changes. Please keep in mind even if we used separate table for storage as Joomla fields do it would still be stored in a single row as a JSON value exactly the same way Joomla repeat fields do.

I am not agree with the suggestion you provided. Could you please let me know what will be the additional cost to make the changes as per my requirement.

We've no plans to implement the changes you are asking for, sorry.

What are you trying to do with the data that would require the storage to be changed? You could use CB Auto Actions and a Code action with Method set to PHP. You could then write custom code to do whatever you like with it using PHP. You could output it with custom parsing using PHP in CB Code Field. You could also output it using a custom template file as its display is template driven.

The storage is not going to change, but it would help to know why exactly you even want to change the storage so a possible solution can be suggested.