Live data from Hacker News

Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

github.com

61–70 of 87 posts

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#61

Earlier quoted context omitted.

Thanks a lot. I did not built it with Typescript, just plain js - I don't use Typescript at all(not my cup of tee), but a kind soul (thanks @minigugus) contributed the typings ;) I actually began it out of curiosity and because I was missing features in the current options. I had been using a wrapper around pg-promise to give me the API i wanted for quite a while, and one day when going through the PostgreSQL documen…

Hey. Love this lib. I am curious why you decided against using TS here? You mentioned it's not your cup of tea.

I can only assume that I've finally found a soulmate that just don't like writing TS code.

Like, in my full-time job I'm using 100% TypeScript, but I don't really ENJOY writing in it - that's why in my all side-projects I use good old JavaScript.

I think it's just a personal syntax preference.

But I don't want to answer this for the OP, just added my 2cents, maybe he has similar feeling about it :)

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#62

Earlier quoted context omitted.

Thanks a lot. I did not built it with Typescript, just plain js - I don't use Typescript at all(not my cup of tee), but a kind soul (thanks @minigugus) contributed the typings ;) I actually began it out of curiosity and because I was missing features in the current options. I had been using a wrapper around pg-promise to give me the API i wanted for quite a while, and one day when going through the PostgreSQL documen…

Hey. Love this lib. I am curious why you decided against using TS here? You mentioned it's not your cup of tea.

Some people really love the simplicity that comes from zero compilation.

I like that too, so I always start with just JS, but then two files in realize I really want my typings.

Now I use esbuild instead of tsc, and I have the best of both worlds.

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#63
post #49

Earlier quoted context omitted.

> How can this be so much faster than even pg-native that uses the C library libpq? the c++ to javascript membrane in v8 is expensive to pass. there are many projects that are faster implementing protocols in javascript vs c/c++ because of this. redis is another.

On the surface I'm not sure this explanation passes the smell test. Almost irrespective of how you get the data from your network card into v8 / nodejs, you're going to be crossing c++/v8 boundaries. It's possible that a native binding goes through this expense multiple times, but that's not likely now most of these bindings work (pg at least for sure). As the author noted elsewhere in thread, the performance gains a…

> On the surface I'm not sure this explanation passes the smell test. Almost irrespective of how you get the data from your network card into v8 / nodejs, you're going to be crossing c++/v8 boundaries.

yes, you are, but the differences are the object creation that occurs. a single buffer coming from c/c++ (a socket, let's say) can be parsed and turned into a large number of objects in javascript much more quickly. yes, you're passing through that barrier once, but creating all of those objects from c++ and passing through it 20-30 times is a lot more expensive.

> Out of curiosity, do you have links to these other projects where they have similar benchmarking attempts/results?

how about pg vs pg-native? https://github.com/porsager/postgres-benchmarks#results

and unfortunately, I cannot find the original discussions from when node-redis went from native to pure javascript, but it was about a 30-40% speed increase originally if memory serves (I was the one who did that original conversion after a lot of deep dives into v8 and performance crossing the barrier).

as an aside, I'm also the maintainer of plv8, and am happy to discuss the same types of performance issues of dealing with jsonb vs json (which in Postgres is text): creating objects vs a simple JSON.parse() in c++ is a significant difference.

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#64
post #27

Thanks porsager. Any plans for Knex support?

> Any plans for Knex support? That question doesn't really make sense. I'm not familiar with this library, but the developer interface is very similar to slonik. The whole point of this is that SQL tagged template literals replace the need for a query builder like Knex. Here is a good blog post from the author of slonik explaining: https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41...

I'm broadly a fan of just writing SQL, but Knex does have one important advantage: it automatically declares the return types from a query based on my DB structure. If I write SQL by hand, I have to annotate the query with the return types, and those annotations can get out of sync with the query.

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#65
post #51

Earlier quoted context omitted.

This can’t be overstated. Crossing the JS native barrier is inherently a perf hit. I’ve measured it trying a large variety of high performance messaging protocols and postMessage with structured clone nearly always wins. If that sounds like a bold claim, there are troves of Node and Deno issues where they’ve improved perf by staying in JS specifically because calling into native and back has been the bottleneck. Ther…

I responded to the OP, but I'll add here too for the conversation. Where are these projects that are implementing network protocols, where the nodejs versions are faster than the native ones? As I noted in my other comment, in -any- of those implementations, you're still going to be required to traverse from libc somewhere to nodejs (even if it's just to read the network data out of the socket and send it to v8). The…

> The performance gains would have to either come from a faster (JIT'd) protocol parser, or from eliminating additional FFI calls (that it isn't obvious why they'd exist).

or, as I noted above, and will try to simplify here:

let's suppose you have a buffer which contains 5 key/value pairs, and you want to convert that into an array of 5 javascript objects in v8.

1. obtain a pointer to the isolate 2. create an array object, and check 3. create 5 objects, and check each one 4. create 5 key objects, and check each one 5. create 5 value objects, and check each one 6. convert each key into a v8 typed object, and check each one 7. convert each value into a v8 typed object, and check each one 8. attach each key to each object, and check each one 9. attach each value to each object, and check each one 10. attach each object to the array, and check each one 11. check that array one more time 12. done

vs.

1. obtain a pointer to the isolate 2. create a buffer, and check 3. parse in javascript

inside of v8, creating a javascript object inside of javascript is much faster than doing the same via c++, because of the additional checks that are needed each time you cross that barrier.

    Local::New(isolate, String::NewFromUtf8(isolate, t).ToLocalChecked());
is an example of simply creating a string, not assigning it into an object.

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#66
post #51

Earlier quoted context omitted.

I responded to the OP, but I'll add here too for the conversation. Where are these projects that are implementing network protocols, where the nodejs versions are faster than the native ones? As I noted in my other comment, in -any- of those implementations, you're still going to be required to traverse from libc somewhere to nodejs (even if it's just to read the network data out of the socket and send it to v8). The…

I think you're right. Here's a project proving the exact opposite of native bindings being slow - https://github.com/uNetworking/uWebSockets.js

I think you might find that a large part of their speedup is by not using any of the openssl trappings of node, and using boringssl instead.

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#67
post #7
post #6

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 mul…

Thanks a lot! What a coincidence - and perfect timing since v3 supports .raw()[1] to receive results as arrays. I'd also be very curious to hear how replacing pg goes :) And also good job on Imba! I'm a really big fan of stripping syntax down to the bare essentials, and what you've done with Imba is really impressive! [1] https://github.com/porsager/postgres#raw

Brilliant! We're well on our way to migrating. The experience has been buttery smooth so far. And the codebase itself is really well organized. Huge thumbs up!

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#68

Earlier quoted context omitted.

Hey. Love this lib. I am curious why you decided against using TS here? You mentioned it's not your cup of tea.

I can only assume that I've finally found a soulmate that just don't like writing TS code. Like, in my full-time job I'm using 100% TypeScript, but I don't really ENJOY writing in it - that's why in my all side-projects I use good old JavaScript. I think it's just a personal syntax preference. But I don't want to answer this for the OP, just added my 2cents, maybe he has similar feeling about it :)

Haha.. There's plenty of us out there, it's probably just that we'd rather do actual stuff than talk about doing it. A bit like Typescript - it doesn't really do anything, it just talks about it.

Joking aside, I generally don't want to get into the debate, because I believe people work differently, and there should be room for doing both things. It's just a bit sad that Typescript is being pushed so hard as if it's the only right way.

Re: Show HN: Postgres.js – Fastest Full-Featured PostgreSQL Client for Node and Deno

#69
post #67
post #7

Earlier quoted context omitted.

Thanks a lot! What a coincidence - and perfect timing since v3 supports .raw()[1] to receive results as arrays. I'd also be very curious to hear how replacing pg goes :) And also good job on Imba! I'm a really big fan of stripping syntax down to the bare essentials, and what you've done with Imba is really impressive! [1] https://github.com/porsager/postgres#raw

Brilliant! We're well on our way to migrating. The experience has been buttery smooth so far. And the codebase itself is really well organized. Huge thumbs up!

Wow - thats awesome! Thank you!
Post reply on HN