Live data from Hacker News

Edge-compatible Serverless Driver for Postgres

neon.tech

41–46 of 46 posts

Re: Edge-compatible Serverless Driver for Postgres

#41
post #20

Earlier quoted context omitted.

That I understand. But of course for the user of the driver it might be fine if that is 2 or more HTTP requests. I expect that is how PlanetScale does it in their transaction implementation, https://github.com/planetscale/database-js#transactions , and I know that is how Prisma Data Proxy handles it - the transaction is identified with an ID which is returned to the Client and then included in further requests for th…

> the transaction is identified with an ID which is returned to the Client and then included in further requests for the same transaction. Yes, and there's a catch there that people might not notice: HTTP-based queries utilize this ID to identify which active transaction to use, but this is vulnerable to concurrent HTTP requests on the same transaction ID, thus allowing query injection (early COMMIT, SELECT sleep(100…

In our case, it's a bit more state than just a transaction ID, but the same concept applies.

And yeah, to mirror the other comment, this isn't particularly something I'd consider a security issue. If an attacker has access to your transaction (session) state, this is a similar risk vector on any web service that utilizes browser cookies or sessions. If someone hijacks your browser cookies, they can do anything they want into your account typically, ignoring 2FA and extra layers.

Same risk here. If someone were to intercept your request, which is strictly over HTTPS, and hijack your session, or you erroneously were logging the session and authentication credentials publicly, then you're exposing yourself to a lot bigger risk than someone adding a sleep() into your session. They could just dump everything from the database, because they are you.

A direct connection only changes this because it's a stateful protocol, and if the connection is severed, everything is lost/rolled back and nobody can intercept that.

But anyways, I'd hardly call a well established security model of HTTP sessions flawed in this regard.

If anything, it's possible for a client to do some dumb things, like, parallel queries within a single transaction, which you cannot do with a direct connection, which ultimately is just... going to be undefined behavior since they fundamentally get serialized into the database, just in an undeterministic order relative to the client.

Re: Edge-compatible Serverless Driver for Postgres

#42
post #38
post #37

Earlier quoted context omitted.

https://github.com/prisma/prisma/blob/main/packages/client/p...

That is only used in tests :) The query engine uses this: https://github.com/prisma/quaint/blob/6532d69b5aec007ad06ac6... (I work at Prisma, could have mentioned that earlier)

Gotcha. I drew my conclusion based on the mentioned package.json. Now wonder why did you decide to go with rust for query engine? Do you compile it into wasm?

Re: Edge-compatible Serverless Driver for Postgres

#43
post #42
post #38

Earlier quoted context omitted.

That is only used in tests :) The query engine uses this: https://github.com/prisma/quaint/blob/6532d69b5aec007ad06ac6... (I work at Prisma, could have mentioned that earlier)

Gotcha. I drew my conclusion based on the mentioned package.json. Now wonder why did you decide to go with rust for query engine? Do you compile it into wasm?

It made sense at the time. We do not only support Node, but also have community Clients in Go, Python or Rust. Right now we are moving more and more parts from a Node-API library or binary engine (the two variants we support until now) over to Wasm modules where it is possible for our Node/TS/JS Client. Socket/TCP connections itself are unfortunately not supported yet, so this will only be partial. And maybe there is also a future where we support Node based databases drives. As this blog post we are commenting on shows, sometimes we have to combine the weirdest things together to achieve our goal.

Re: Edge-compatible Serverless Driver for Postgres

#44
post #34

Earlier quoted context omitted.

To elaborate Neon is designed deliberately to plug into the Postgres ecosystem. So all of the ecosystem works out of the box. Supabase seems to be vertically integrated. But Paul should comment on that

I believe most of the tools that Supabase use would work with Neon, with the exception of Realtime. As I understand it, Neon doesn't support Logical Decoding yet[0], which is required so that the Realtime engine can receive updates from the database. [0] https://community.neon.tech/t/plans-for-logical-replication/...

(Another one would be the GraphQL extension: https://github.com/supabase/pg_graphql/)

Re: Edge-compatible Serverless Driver for Postgres

#45
post #38
post #37

Earlier quoted context omitted.

https://github.com/prisma/prisma/blob/main/packages/client/p...

That is only used in tests :) The query engine uses this: https://github.com/prisma/quaint/blob/6532d69b5aec007ad06ac6... (I work at Prisma, could have mentioned that earlier)

While you're here, I want to mention that I never understood why Prisma couples so much the query builder (which IMO is the really best part of Prisma) to the query engine / DB driver (which is not differentiated at all as a product). I have 1000 ideas of really insanely cool thing we could do if Prisma could just spit up SQL query strings, or at least connect to a custom driver.

Re: Edge-compatible Serverless Driver for Postgres

#46
post #45
post #38

Earlier quoted context omitted.

That is only used in tests :) The query engine uses this: https://github.com/prisma/quaint/blob/6532d69b5aec007ad06ac6... (I work at Prisma, could have mentioned that earlier)

While you're here, I want to mention that I never understood why Prisma couples so much the query builder (which IMO is the really best part of Prisma) to the query engine / DB driver (which is not differentiated at all as a product). I have 1000 ideas of really insanely cool thing we could do if Prisma could just spit up SQL query strings, or at least connect to a custom driver.

Prisma often does multiple queries when getting some specific data, the first only leading to the second and so on. But we might very well get there one day. You are not the only one asking for this: https://github.com/prisma/prisma/issues/5052
Post reply on HN