We already had serverless db for ages and it's called ... Google Sheets. You can even query it with simple SQL-like language.
The problem with most other "serverless" databases is that they don't offer HTTP API to query them from restricted environments like serverless functions.
Good job, Mastercard (and Visa)! Now all people opposing Putin and trying to gather money for leaflets will have to use state-created MIR instead. Putin will be pleased!
I, personally, feel like this is a rather pointless addition to an already somewhat bloated language. It it isn't saving that much typing (we have NATURAL JOIN's already, nobody is using them), is kind of inconsistent with other language principles (we should be able to join anything to anything if we need to, see SQL-89) and limits JOIN flexibility (you don't have to join with "=" operator, JOIN's supports different types of conditions and are equivalent to WHERE clause)
Nobody is using NATURAL because usually it’s broken and doesn’t do what you want it to and for any more complex joins or joins on other than = you would still use JOIN ON, what’s the issue? JOIN was introduced when we had multiple tables in the FROM clause and conditions in WHERE for clarity and convenience, why are people so opposed to this change then?
The issue, as i see it, is that adding this feature complicates the language parser even more for not that much actual gains.
1) Implementation has to do some nontrivual rewriting into actual JOIN's which uses indexes, previous special cases like NATURAL were purely syntax sugar
2) All of the tooling that depends on parsing SQL need to add sensible support or else noone will even recommend to use this
3) It is useless for anyone using ORMs in the first place, they will continue to generate normal JOIN's (less actual impact)
4) For anyone using prepared statements it automatically goes to "is not recommended to use" list because it makes your JOIN's depend on existence of foreign keys and corresponding indexes, which are an optional feature DB still should work without. I've had tasks in my career when my team added or removed foreign keys, so this type of JOIN's would make migrations even harder to do.
5) So considering all of the above this is feature designed purely for REPL and for this purpose it is also kind of useless. I can imagine remembering and typing column names in normal JOIN's, but foreign keys usually have some long unintelligeble autogenerated name.
Basically I think this syntax addition is nonorthogonal, isn't making SQL any more powerful, but isn't solving the main usability problem, which is composability of queries in any way. Like writing JOIN's is not complicated if somewhat wordy already.
There is also an interesting solution to this problem: use native WebView, so you don't have to pack the whole Chrome with your app. Basically every "electron alternative" with HTML+CSS+JS works this way.
You'll have a little bit more testing to do, as the web-views shipped by different OS might not be exactly in sync feature wise, but if your app is really simple it shouldn't be much of a problem.
