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.
This one just made my day. Thanks. I remember trying to build a tool at work with as little as possible dependencies (in python) and how satisfying it was to see quite a few dependencies just being wrappers replaces with 5 lines of my own code that i could easily audit and ensure no supply chain attack was possible for that functionality.
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