plv8 VS surrealdb

a bit more than an experiment at this point. pljs, even in its early state, has some very good results: https://github.com/plv8/plv8/issues/531#issuecomment-1627883...

passing through v8's javascript/c++ membrane has always been painful, and appears to be getting worse.

From here you'll write a send_email function in Postgres that calls the API. I initially wrote the entire function in PLpgSQL and spent an entire day to get it debugged and working. And even then I wasn't happy with it. In my opinion that language is unintuitive and difficult to learn and debug. I switched over to PLV8, an extension for Postgres that supports writing functions in Javascript. It takes one click in the Supabase UI to enable this extension, and it will save hours and hours of time.

You jest, but the evil geniuses at plv8 have already done it for Postgresql.

To be honest I haven't used it, but I've extensively used pl/pgsql and a little pl/ruby, and know that https://plv8.github.io/ exists - it might be what you're looking for and it's on my list of things to play with

but, let's take your straw man a little further. let's suppose that all of the actual parsing is done for you already, and all you're doing is iterating through the data structure, creating objects through the c++ api, and calling it good. that should be faster than calling the c++ JSON.parse(), shouldn't it? since we don't have to actually parse anything, right? no, it's actually much slower. you can see this in action at https://github.com/plv8/plv8/blob/r3.1/plv8_type.cc#L173-L60...

again, we're not talking about whether javascript in an interpreter is faster than c++, we're talking about whether v8's api causes enough slowdown that some workloads that require a lot of data between c++ and javascript are slower than the same workload that requires very little data between c++ and javascript ... because passing through v8's c++/javascript membrane is slow.

you should add https://surrealdb.com -- basically an open source firebase. and they will launch a paid cloud offering soon.

In this article, I have shared how I have built a simple task-tracking full-stack application using NextJS and SurrealDB.

In this article, I'll show you how you can create a binary package for your desired program. I wanted to download the SurrealDB package, but the package on nix was a source package, meaning that I had to spend over 50 minutes waiting for a stupid package to compile.

Get Cloud Version going!

SurrealDB comes with a LIVE SELECT statement that allows you to listen for creations, updates and deletions to specific records you are interested in or entire tables. While you could already take advantage of this powerful feature with our JavaScript SDK or WebSockets, the Rust SDK added an API for it in v1.1.0. ​ The Rust API for live queries builds on top of the already existing select method by simply adding a live method which converts the select query into a live select one. It works seamlessly with our current API, so you can use it with single records, a range of records, or entire tables. Unlike the normal select method which returns either a single result or a vector of results, it returns a stream of notifications. This works for the WebSocket engine and the local ones (the key value stores you can embed in your app). The only engine not yet supported is the HTTP one. ​ In this article, we show some examples of running live queries via the Rust SDK. We will skip imports for brevity but your IDE and/or the Rust compiler should give you the correct suggestions. Please refer to this example in our repo for a full, working example. ​

1.0 version but https://github.com/surrealdb/surrealdb/issues/1548 is still open :)

In the midst of a dynamic landscape of exciting new projects, one name shines bright — SurrealDB.