plv8 VS Marten

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 can check Marten, that I was co-maintaining: https://martendb.io/. It doesn't have MongoDB-compliant API, but it's mature, stable and efficient.

Id recommend trying out MartenDb. It's not really a PostgreSQL ORM, it actually uses Postgres more as a document database via jsonb. But it's excruciatingly easy to use and schema updates are a breeze (and largely automatic)

Check out Marten for a fully fleshed out implementation https://github.com/JasperFx/marten

We are using ExtCore here to make our app modular: https://extcore.net/, and MartenDB for event store (which is surprisingly VERY simple) : https://martendb.io/

I always loved Marten, it is so simple to use and yet powerful. If you are unfamiliar with it, it is a data access library (like an ORM) that is using JSON serialization and LINQ to store and query data from/to Postgres. It basically turns Postgres into document DB. Comparing it to EF, Marten doesn't require migrations since it stores documents.

You're better off using Postgres (has JSON columns.) If you want a more "document" oriented experience, use Marten: https://martendb.io/

For that part, the samples use EventStoreDB (https://www.eventstore.com/), which is the only mature event store I know in Node.js land. Event Sourcing allows using any database as backing storage. I'm co-maintainer of the Marten (https://martendb.io/), which is a .NET library that allows using Postgres as event store and document db.

Then you should check out Marten (https://martendb.io/). Our intention is to remove the boilerplate, we're using Postgres e having the built-in projections.