Show HN: PLJS – JavaScript for Postgres

9 points by jerrysievert 18 hours ago

PLJS is a new, modern JavaScript trusted language extension, bundling QuickJS, a small and fast JavaScript runtime with Postgres, providing fast type conversion between Postgres and JavaScript, fast execution, and a very light footprint.

Here are bencharks that show how it compares to PLV8: https://github.com/plv8/pljs/blob/main/docs/BENCHMARKS.md

This is the first step toward a truly light-weight, fast, and extensible JavaScript runtime embedded inside of Postgres. The initial roadmap has been published at https://github.com/plv8/pljs/blob/main/docs/ROADMAP.md

You can join the discussion by joining the PLV8 Discord: https://discord.gg/XYGSCfVNBC

You can find PLJS at https://github.com/plv8/pljs

phartenfeller 16 hours ago

Interesting. This is now the second DB next to Oracle[1] that can do JS (that I know of). pgSQL and PL/SQL of course still stay relevant but in the Oracle spehere the argument is that you can reuse existing code from NPM. Like this blog post [2] describes how to run an GraphQL endpoint from within the DB.

[1] https://docs.oracle.com/en/database/oracle/oracle-database/2... [2] https://blogs.oracle.com/developers/post/creating-a-graphql-...

  • jerrysievert 16 hours ago

    PLV8 (the predecessor to this project) was released in June of 2012. It provided JavaScript as a trusted language extension to Postgres 9.2.

    PLJS is a newer generation.

mhio 11 hours ago

What are the advantages to pljs over plv8? I thought the context creation would have been the big one, but it doesn't appear so in the current benchmarks.

How did the project weigh the intermittent updates of bellard quickjs and the community fork quickjs-ng?

  • jerrysievert 9 hours ago

    I too was surprised about the slower startup and am planning on spending a lot of time in the quickjs repo to try to improve it. Thankfully most use cases use a connection pooler, which removes startup costs from the equation, leaving conversion speed much more important. I was able to speed up conversion of jsonb by writing a custom conversion from jsonb to quickjs and back, but feel there is still a lot of room for improvements.

    As for quickjs vs quickjs-ng: ng is a fantastic project and I’m really hoping it pulls an egcs and ends up canonical, but when this project was started, it did not exist, so quickjs was chosen as the starting point. As for why it has not been adopted yet by this project, it comes down to a few things that helped make the decision:

      * quickjs is still having releases
  * as learned from plv8, when there are constant changes it becomes much harder to maintain, so a steady target is easier to deal with (this is constantly being evaluated)
  * the build system change from make to cmake adds friction to Postgres embedding, I already have to patch quickjs, and would need more complicated patches for quickjs-ng. I have a good working relationship with Ben Noordhuis, but it’s still a source of friction that isn’t needed now.
    As things change, everything will be re-evaluated, but for now quickjs itself works great.
revskill 3 hours ago

No npm support is a huge limitation.

timz 16 hours ago

Amazing.. Would be nice to have something like that for Redis to replace Lua

oulipo 16 hours ago

What would be the typical use-case? Light data transformation?

Is there a significant advantage over Rust-based embedded Postgres language like https://github.com/tcdi/plrust which is compiled and a bit more type-safe?

  • tehlike 16 hours ago

    A lot of logic just becomes easier with javascript. If you have complex-ish trigger logic, or a procedure etc - doing these in pl/pgsql is just hard if not intracatable. Also allows up reuse of a lot of code that people have built with npm - even if not directly with require(), it becomes possible to bundle compiled binary.

    I used this for storing patches of data (to save space, compression is a pain in Postgres) and applying runtime to show full version etc. It's fun.