Can you write a content why postgres is faster than pg?

[samchon]

I love performance tunings. I'm drawn here by your benchmark results.

By the way, I think it would much better if you describe the reason why this library is faster than pg.

Because I'm personally curious, and if do not explain why, there may be some people who doubt it.

[porsager]

That's a lovely thought @samchon, and I have described that in various places before (think I also touched on it in the js party podcast https://changelog.com/jsparty/221), but as much as I wanted to I don't think I have the time for it..

Also, btw, it seems Postgres.js is actually faster than, not only pg, but of any driver out-there - https://porsager.github.io/imdbench/sql.html

[porsager]

You're right, that came out a bit sour, but I have no skin in the game or interest wrt. to prisma, but I wouldn't mind a PR

[leeoniya]

but I have no skin in the game

imo, this first claim in your readme implies otherwise:

the burden of proof is on the claimant, and it's very different to claim to be "faster than every" than to say "faster than many" or "faster than most". as you know, benchmarks age very poorly. ones that are unmaintained are as good as useless, since libs with active development often have drastic perf changes, not to mention Node or V8 version changes, hardware advances, kernel updates, etc.

of course, you're free to spend your time how you want. i would consider contributing a benchmark here, but i don't currently use PG, so it's not trivial for me. anyways, i've done my share of benchmarking third-party libs and keeping them current (if only to keep myself honest) [1][2][3] :)

🍻

[1] https://github.com/leeoniya/uPlot#performance
[2] https://github.com/leeoniya/uFuzzy#a-biased-appraisal-of-similar-work
[3] https://github.com/leeoniya/uDSV/tree/main/bench

[porsager]

Great nerd sniping @leeoniya 😅 You've got me trying to add prisma here now 🙈

First I have to applaud your effort benchmarking all those libs - great work!

But for me trying to add prisma here is testing my patience.

Now I finally figured out how to get it to work and generating things with their cli, but I wasn't able to run my select_where test because prisma threw errors due to not supporting columns[1] with the regproc type. I rewrote it to use pg_timezone_names instead, but somethings still wrong because it threw errors about pool connection timeouts. I removed the timeouts, and ended up with ~200x slower queries, so clearly somethings still wrong. You can see a sample run here below. (disregard select_where)

client	select	select_arg	select_args	select_where
postgres	0.057s (5.1x)	0.061s (5.2x)	0.124s (3.3x)	0.096s (211.4x)
prisma	0.292s (1.0x)	0.314s (1.0x)	0.408s (1.0x)	20.293s (1.0x)

Even so - I see no reason to add it because I found it already present in the imdbench setup where it is even below sequelize (based on pg), and Postgres.js is at the top running against faster languages. Perhaps I should add a note pointing that out for anyone curious about prisma.

[leeoniya]

great :), i think it's sufficient to point to another recent bench that shows it to be slower than a lib you bench here 👍

[danil-iglu]

@porsager you can run prisma at postgres.js speed, it's not a problem. Just prebake SQL on generation time and enjoy https://www.npmjs.com/package/prisma-sql