How NoSQL forced the evolution of a scalable relational database
I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript.  While scaling is one of the advantages, I'd be super surprised if many people actually need scaling capabilities ( other than because their design is super inefficient ).Recently I've been inspired to play around with kicking out as many layers between a relational db and a REST Api, largely because I've been watching https://www.twitch.tv/nybblesio  ( who I first came across here on HN on a thread about live coding via twitch streaming ).   One of his projects he works on is a SASS product which is largely done in postgresql leveraging  https://github.com/PostgREST/postgrest  .  Seems pretty good, going to be interesting to see how it turns out   ( though I haven't seen him work on it lately )I tend to like SQL Server, ASP.NET Core and found https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018...    and I've been playing around with this kind of idea and using a lightweight mapper when needed ( https://github.com/StackExchange/Dapper which the stackoverflow people created )I gotta say, I kind of like itOne of the problems of many stacks is that the frameworks wrap general purpose languages over SQL, which, is not really a good idea, SQL is a vastly more capable language for dealing with relational data and layers built over the top often dumb down the database.The REAL problem SQL wrappers need to solve is that most languages don't have a good interface with SQL.  So most often SQL is handled in strings and manipulated with string manipulation and there is no type safe way transitioning data from the DB to a general purpose language.Microsoft at one stage had Linq to SQL which was quite good..... but they killed it :)