Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgresJs: PostgreSQL client for Node.js and Deno

github.com

Post reply on HN
Print view View original

81–90 of 148 posts

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#81

Post by sgarland »

reducesuffering wrote: post #73
sgarland wrote: post #25

Earlier quoted context omitted.

Prisma doesn't do JOINs [0], it just SELECTs everything and joins them in its own engine. It should not be taken seriously. [0]: https://github.com/prisma/prisma/discussions/12715

I thought the webdev startup shtick is to build fast and optimize speed where your bottlenecks are later. If Prisma helps you write 90% of your queries faster, you can still just drop down to SQL for efficient joins the rest of the times.

IME it’s more like “build fast and then blame the DB later when it’s slow.”

I’m begging devs to learn the absolute basics of SQL and relational algebra. It isn’t that hard.

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#82

Post by halfmatthalfcat »

sgarland wrote: post #79
halfmatthalfcat wrote: post #74

Earlier quoted context omitted.

I think the access pattern that Prisma uses (for a given records from X, give me it's relations to Y, then give me Y's nested relations to Z in a unified data model), using multiple queries may the the _best_ way (not necessarily the most efficient) to do it to produce the resulting object model. If you were to do this with joins, you'd have a ton of duplicated data returned (via returning every column from every tab…

> If you were to do this with joins, you'd have a ton of duplicated data returned (via returning every column from every table to have all the relevant data) ARRAY_AGG for Postgres or GROUP_CONCAT for MySQL does what you’re asking without duplicating rows. Re: JSON, don’t. RDBMS was not designed to store JSON; by definition you can’t even get 1st Normal Form once its involved. IMO, claims of DX regarding SQL just mea…

After writing a lot of SQL over the past 10 years, I'm ready to not do it anymore lol. If I could never worry about syncing models with schema changes, hand writing migrations, etc, I would be happy. Most SQL work is CRUDy and monotonous to write. Prisma allows you to break out of the query builder with their "rawX" variants too and write plain SQL if you never need to (and I do occasionally).

Again, not saying you _cant_ do it with current db constructs but Prisma deals with all that for you while allowing escape hatches if you need them. Just like with anything related to software engineering, there are footguns a plenty. Being aware of them and taking the good while minizing the bad is the name of the game.

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#84

Post by [deleted] »

joshxyz wrote: post #27

reposting my comment on its benchmarks: On what makes it postgres.js faster, from author himself: > it seems Postgres.js is actually faster than, not only pg, but of any driver out-there - https://github.com/porsager/postgres/discussions/627 - https://porsager.github.io/imdbench/sql.html

[deleted]

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#85

Post by sgarland »

halfmatthalfcat wrote: post #82
sgarland wrote: post #79

Earlier quoted context omitted.

> If you were to do this with joins, you'd have a ton of duplicated data returned (via returning every column from every table to have all the relevant data) ARRAY_AGG for Postgres or GROUP_CONCAT for MySQL does what you’re asking without duplicating rows. Re: JSON, don’t. RDBMS was not designed to store JSON; by definition you can’t even get 1st Normal Form once its involved. IMO, claims of DX regarding SQL just mea…

After writing a lot of SQL over the past 10 years, I'm ready to not do it anymore lol. If I could never worry about syncing models with schema changes, hand writing migrations, etc, I would be happy. Most SQL work is CRUDy and monotonous to write. Prisma allows you to break out of the query builder with their "rawX" variants too and write plain SQL if you never need to (and I do occasionally). Again, not saying you _…

I’m all for using a library to help you with migrations, and even a full ORM like Django has its niceties. As a DBRE, I just want the end result to be performant, scalable, and to encourage good SQL habits.

Knowing SQL can help inform the choices a dev makes in the ORM - for example, knowing about semi-joins may let you write code that would cause the ORM to generate those, whereas if you didn’t, you may just write a join and then have to deal with the extra columns.

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#86

Post by lolovaldez »

Have to say, if you like to do bare metal SQL, using the nice features of Postgres, working with this lib is a total Joy!

No “fancy” and bleeding abstractions like something like Prisma, not convoluted type annotations like other TS libs, no, just plain SQL statements in the best JavaScript way of doing it.

I discovered learning to do Postgres a couple years ago, after getting sick of trying to hack Prisma, tried out several others, and after a couple minutes using this, i knew I wasn’t going back.

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#88

Post by xctr94 »

hhfdsbvc wrote: post #24
xctr94 wrote: post #17

Earlier quoted context omitted.

We had to abandon Zapatos because a) it doesn’t support multiple schemas; b) the types wouldn’t always be very readable. PgTyped was the alternative, and 2 years later I’m very glad we made the switch.

Ever try drizzle?

I haven’t, but it’s an ORM so an automatic no. We tested 6 ORMs before deciding that plain SQL with introspection was the way to go. No regrets.

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#89

Post by ndriscoll »

noduerme wrote: post #14
latch wrote: post #13

Earlier quoted context omitted.

If you're using parameterized queries, then you _have_ to use PostgreSQL's "Extended Query" flow, which is what most people would think of as a "prepared statement". This is hardly opinionated. But normally, you use an unnamed prepared statement and/or portal, which PG will clean up for you, essentially only letting you have one of those per session (what we think of as a connection). I agree that sentence didn't mak…

Thanks... I haven't got the mental energy to follow their code ATM but yeah, it seems weird to buffer a static query as a prepared statement if it's only going to be used once. Maybe that kind of goes with a Nodejs philosophy, though? It seems like an assumption that in most cases a static query will recur... and maybe that's usually accurate with long running persistent connections. I'm much more used to working in…

I believe it's typical for database libraries with auto-prepare to also have batch statement sending (and use it for prepare-executes), so there's no real cost to doing the prepare. The database has to parse/plan the statement regardless, and there's no round-trip delay with statement batching.

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#90

Post by xctr94 »

Exuma wrote: post #20
xctr94 wrote: post #17

Earlier quoted context omitted.

We had to abandon Zapatos because a) it doesn’t support multiple schemas; b) the types wouldn’t always be very readable. PgTyped was the alternative, and 2 years later I’m very glad we made the switch.

What do you mean multiple schemas ? What is an example of a non readable type?

I didn’t know support for schemas had landed, but the docs still seem obtuse for joins and upserts. Compared to plain SQL files in PgTyped — which admittedly needs some annotations to work, and lacks transactions —, I find the lateral joins in Zapatos really verbose and ugly. Lots of extra parameters too.

Which isn’t to say it’s not a great tool! You pick what you like :)

Post reply on HN