-
postgres
Postgres.js - The Fastest full featured PostgreSQL client for Node.js, Deno, Bun and CloudFlare (by porsager)
It greatly outperformed the alternatives[1] using pipelining and prepared statements, while providing a much better development experience safe from SQL injections. Since then I've been busy building things using it, now running in production, and although quite delayed I'm so happy to release a new major today with some really exciting new features:
1. Realtime subscribe to changes through Logical Replication [2]
It's now possible to use logical replication to subscribe in realtime to any changes in your database with a simple api like `sql.subscribe('insert:events', row => ...)`. Inspired from Supabase Realtime you can now have it yourself in Node.
2. A Safe Dynamic Query Builder
Nesting the sql`` tagged template literal function allows building highly dynamic queries while staying safe and using parameterized queries at the same time.
3. Multi-host connection URLs for High Availability support
It's really nice to be able to quickly spin up a High Availability Postgres setup using pg_auto_failover[3] and connect using Postgres.js with automatic failover and almost 0 downtime.
4. Deno support
It also works with Deno now, completing all tests except a few SSL specific ones which requires fixes in Deno.
5. And much more
Large object support, efficient connection handling for large scale use, cancellation of requests, Typescript suport, async cursors.
[1] https://github.com/porsager/postgres-benchmarks#results
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
postgres-benchmarks
A set of benchmarks focusing on the performance of Postgres client libraries for Node.js
It greatly outperformed the alternatives[1] using pipelining and prepared statements, while providing a much better development experience safe from SQL injections. Since then I've been busy building things using it, now running in production, and although quite delayed I'm so happy to release a new major today with some really exciting new features:
1. Realtime subscribe to changes through Logical Replication [2]
It's now possible to use logical replication to subscribe in realtime to any changes in your database with a simple api like `sql.subscribe('insert:events', row => ...)`. Inspired from Supabase Realtime you can now have it yourself in Node.
2. A Safe Dynamic Query Builder
Nesting the sql`` tagged template literal function allows building highly dynamic queries while staying safe and using parameterized queries at the same time.
3. Multi-host connection URLs for High Availability support
It's really nice to be able to quickly spin up a High Availability Postgres setup using pg_auto_failover[3] and connect using Postgres.js with automatic failover and almost 0 downtime.
4. Deno support
It also works with Deno now, completing all tests except a few SSL specific ones which requires fixes in Deno.
5. And much more
Large object support, efficient connection handling for large scale use, cancellation of requests, Typescript suport, async cursors.
[1] https://github.com/porsager/postgres-benchmarks#results
-
There is quite a big difference, but I'll highlight some of the main points here. Note I'm the author of Postgres.js so I might be biased.
Slonik is a wrapper around another node driver (pg), so it's performance is the same as that, where Postgres.js is significantly faster (2-5x)[1].
Postgres.js is also a zero dependency module, whereas Slonik has quite the dependency graph meaning - compare https://npmgraph.js.org/?q=slonik with https://npmgraph.js.org/?q=postgres. That makes it more difficult to audit the code and preventing chain attacks etc.
Slonik also doesn't have the same lean straight forward developer experience as Postgres.js - again I'm biased saying that ;)
Postgres.js also does things that will make your queries perform better out of the box by implicitly creating prepared statements and using pipelining.
I suppose you could build Slonik on top of Postgres.js instead of pg as well, but that would probably only make sense if migrating to Postgres.js.
[1] http://github.com/porsager/postgres-benchmarks#results
-
What a coincidence seeing this on HN. Great lib! I actually experimented with replacing our use of node-postgres with this today. Your lib was the reason I finally got around to shipping support for tagged template literals in Imba today (https://github.com/imba/imba/commit/ae8c329d1bb72eec6720108d...) :) Are you open for a PR exposing the option to return rows as arrays? It's pretty crucial for queries joining multiple tables with duplicate column names.
-
Any reason you can't use MIT.
For hobbyist projects Unlicense is great, but it may create issues with bigger companies. I think the main sticking point, is public domain that doesn't really exist in countries like Germany, so the unlicensed is unclear. Companies don't like unclear things.
Facebook uses MIT, and their tools like React and Jest are cornerstones of the NodeJS ecosystem.
https://github.com/facebook/react/blob/main/LICENSE
-
-
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.
