> developers are in most cases forced to use unfamiliar programming languages, typically unique to the database itself.
What parent correctly points out is that this simply isn’t true. Your examples of novelty are all things that were possible decades ago in most mainstream DBMSes. The SQLite one in particular is bizarre: it’s inherently an embedded db with bindings in every language.
Supporting user defined functions as compiled objects loaded into the database is as old as the hills. The sandboxing part is silly since no one in their right mind is going to expose their database to untrusted users in the first place.
EDIT: Though to be clear, it does seem a terrible idea to me too....even when you prevent unauthorized access, there is always the issue of resource usage.
Apologies, I should have said something more like “exposing the database to untrusted users is a specific and narrow use case that needs way more db-specific planning”. RLS is really cool tech but you need to design your schema and application around it for it to be useful. Slapping some WASM on any existing databases (especially the vast majority which have nothing like the unique capabilities provided by RLS) isn’t going to buy anything that doesn’t exist already.
Also Hasura and PostgREST (thus by extension Supabase). I would also add that one of the entry barriers of such projects is the need to write UDF. Most developers are not used to write UDFs, and the languagea (plsql and likes) themselves lack the features and ease of modern languages and vary among database vendors.
As mentioned by other people there have been attempts to allow writing UDF using the JVM, Javascript, Python and so on, by they never caught on (and some of them are difficult to install) and are not that portable to other database vendors, they require installing third party extensions and so on.
I for one see WASM to be a good candidate for a really portable solution.
I think the fact that the most viable way to run Rust on the JVM right now is by compiling to WASM really says it all. JVM is going to die, WASM is the future.
>The sandboxing part is silly since no one in their right mind is going to expose their database to untrusted users in the first place.
That's circular logic. You would not do it when it's unsafe. But when it is, it could open up entirely new use cases. Most obviously, infrastructure-as-a-service offerings.
It’s only circular when your conception of “safety” has a single dimension. The sort of execution sandboxing provided by WASM runtimes isn’t even close to the primary challenge with allowing untrusted users to run code inside a database.
In the general case using WASM as an object format does nothing to actually enable this use case beyond what exists.
It doesn’t really matter since this “untrusted user functions in the db” scenario is incredibly niche. The vast majority of database usage involves data access patterns entirely controlled by the developers of the system. Stored procedures in a variety of languages have long been available to such developers _and are generally considered an anti-pattern_.
> developers are in most cases forced to use unfamiliar programming languages, typically unique to the database itself.
What parent correctly points out is that this simply isn’t true. Your examples of novelty are all things that were possible decades ago in most mainstream DBMSes. The SQLite one in particular is bizarre: it’s inherently an embedded db with bindings in every language.
Supporting user defined functions as compiled objects loaded into the database is as old as the hills. The sandboxing part is silly since no one in their right mind is going to expose their database to untrusted users in the first place.