Re: I don't understand the motion
Real reason nosql was used and is still used in speed critical and reliability critical applications such as air traffic control? Speed. Indexing in SQL for speed on highly related data often takes a lot of custom faffing around (I know we did it for > 10 years), in a good NoSQL db this is inbuilt, sometimes you may need to indicate a property on a field requires indexing, but often the out of box solution (VDB & Realm) is fast enough. backups can be done within engine/or within filesystem, or within separate programmability
When a full SQL Server instance takes 10 hours to insert 1 million of the same records that velocitydb takes 12s on the same system for then there is a big bloody problem with using SQL for any kind of large-scale input/output.
Another reason NoSql is often preferred by developers - no separate install. Using most SQL systems means having to separately install the sql server (or have an online one running). The SQL systems (like SQLite) that can be packaged as part of an application are large and very slow. Most NoSQL packages can be included in your codebase to run when the application runs (in this situation)
Complex models - In NoSQL I can have a DB model that contains a list of non-db models which each in turn references a different db model type in a relationship. I cannot do that on SQL and have the queries work on it, the non-db model inside the db model would itself have to be it's own table even if the lookups would never query for that table-data in a solitary context.
Native models - Allows pulling data out in a native format used by the code, whether it is C#, C++, even FE scripting languages (although if you are after speed, scripting kinda makes that a bit pointless).
Entity Framework does NOT do this by default, and requires console commands to be run for each migration or model change, and requires careful planning to avoid breaking the model -> db or db-> model relationship. The liklihood of a user requiring SQL native output is pretty low, usually the data goes through an application first, this removes the conversion step that SQL requires to take flat-file data and convert it into 3d models.
Easier migration - handle your migration in code, either leave a new column null or add a default value, or work out the correct value of the new column from other fields on the old data.
The arguments against anything new on behalf of SQL remind of the arguments used in pro-PIC dbs back in the 80's. and if you've ever had to use PIC you would understand how wrong those were on a fundamental level, the complaints of not being able to store multiple pieces of data in one field missed the fundamental difference of how sql didn't rely on you knowing already what datatype the field had to provide for the info. The issue I see is you approach this like it is MSSQL or Oracle when the way the data is organised is fundamentally different and allows for different things.
So lets take a look at your arguments briefly
Managable - NoSQL generally doesn't require much management, migration data that needs to change is put into code. Sharding and other facets like geo-replication can be handled externally or manually in many ways, the speed increase allows for greater flexibility and a LOT more control in this regard as you are not limited by the tooling within the db itself. SQL has the advantage that you can mix and match data from different sources easier rather than having hardcoded relationships, but you can do this with a graphdb, nosql is built around the models being input and output so it cannot do this wihtout setting models up to do it (although a lot do allow either SQL or SQL-like queries on the data)
Extensible - yeah not sure what you mean by this, most good NoSQL dbs allow for more extensibility in that they allow extensions to the core functionality of the db at a code level, something SQL doesn't allow except at the surface level in the case of stored procedures and that autoprogrammability at a SQL level (not at the core code level). Some of them do not have stuff like stored procedures or views because they are redundant due to the way the db works, in other cases you can do something similar to graph calls within a nosql db to get a view.
Reliable - for anyone using Azure MS SQL instances will know what it is like when they update the db and bugger the connection up. Or simply the price of running a instance on the equivalent of a computer from 10 years ago.
Running it yourself on your own server MSSQL is finniky about what else is on there in services and will often fail if the server is not setup in a specific manner. Running on local systems is terrible as AV programs can and will interfere, and remaining up to date on client computers (when used in applications) is not easy as there are breaking changes between versions that disallow downgrading.
Autobackups are great but nosql only require minor changes to code to organise or you can setup your OS to do them.
All the abover being said, if you have a stable system then sql will be good.
The big difference is that now you simply organise your code the way the program/application requires, no more DB manager required unless you are running on a multi-instance web-accessible way. (then it would be a server admin not a db admin).
The one downside seems to be scaling out with a ton of data, but both velocity and realm both handle this quite well (why Mongo bought the cloud version of Realm to run it's backend).
All of the above being said, the only time I can see a graphdb being useful over both NoSQL and SQL is when you want to use it for neural networks and other association based things. I have never come across graphql being more useful than SQL or NoSQL calls. (I guess maybe if you have a dynamic method of calling the data and need highly variable amounts of data for those calls?)
The above is probably poorly worded I don't have time for anything else, so sorry.
Biting the hand that feeds IT
