Edge-compatible Serverless Driver for Postgres

https://neon.tech/blog/serverless-driver-for-postgres/

by carlsverre • 4 years ago

69 44 4 years ago

nikita10• 4 years ago

I’m Neon CEO. Happy to answer questions. We also have an interesting roadmap for the driver where we hope to keep driving latency and number of round trips down

pbiggar2• 4 years ago

Does Neon scale down storage? I'm paying GCP a lot for storage I don't use, and it's incredibly frustrating - they scaled me up no problem but won't let me scale down.

nikita10• 4 years ago

Storage is multi tenant and bottomless. Unused storage spills to S3 and is cheaper. We pass savings to our users

bilalq• 4 years ago

I don't see pricing listed anywhere. Can you expand on what that might look like? Also, can Neon scale down to zero like serverless aurora v1, or is there a minimum capacity unit?

nikita10• 4 years ago

Pricing is coming very soon. Dotting the is and crossing the ts

sakras• 4 years ago

I’m curious why not implement websockets into Postgres natively instead of relying on a proxy server? Wouldn’t that be the way to minimize latency?

neuronexmachina• 4 years ago

Being able to connect to arbitrary Postgres servers (or potentially even the postgres compatibility-layers for AWS's Aurora or Google's AlloyDB) seems like a good reason to go for the proxy approach.

jtmarmon• 4 years ago

Would be really cool to see you guys become a managed service on Fly.io - see what they did with Upstash & Redis:

https://community.fly.io/t/preview-managed-upstash-redis-wit...

They don't have a managed postgres offering yet ("this is not a managed postgres" - https://fly.io/docs/postgres/getting-started/what-you-should...)

krashidov• 4 years ago

Hey Nikita, what are the key differences between neon and Supabase?

nikita10• 4 years ago

I think we innovate on different parts of the stack. Neon is offering separation of storage and compute and serverless. Theoretically you can run Supabase on top of Neon

Sujan9• 4 years ago

The "How it works" section surprised me - I did not expect to see Websockets there.

Other serverless drivers or database APIs (PlanetScale Serverless Driver, AWS RDS Proxy or Prisma Data Proxy) usually use HTTP to replace the stateful TCP connection. The post explains a bit why this might be beneficial (can use existing tools, and use connection state) - but what about the other benefits and use cases of going with HTTP?

For example in that architecture the connection pool also moves from the application to the component in between and all that complexity can completely be removed from the app. Especially on serverless platforms, where in theory each request gets its own application with its own pool, that is huge. How does that work here? Or does the pool also move to the "WebSocket-to-TCP proxy" and you just did not highlight it in the post? (The graphic shows a "Connection Pool" but I can not really make sense of what that means.)

gmac2• 4 years ago

Right: at a basic level, using WebSockets lets us change as little as possible from the user perspective. You get an ordinary Postgres session with an ordinary Postgres driver, full control over transactions, and so on.

At this point, your serverless function establishes a new Postgres connection on each call. We do pooling on the server side with pgBouncer, which means we can handle lots of simultaneous connections (which is what this approach generates). It's true that this approach doesn't fully optimise for low latencies. But, as Nikita has mentioned elsewhere in this thread, we have a roadmap for bringing latency down in a number of different ways over time.

Sujan9• 4 years ago

Ok, so to make that explicit: If I want to do 5 parallel queries on my serverless function I should still have a connection pool size of 5 in my application, which will be fine as PgBouncer ensures there are plenty connections to open and use from the database server side. Correct?

mattashii2• 4 years ago

HTTP does not (easily) allow for using answers of earlier queries in the transaction. E.g.

    BEGIN;
    INSERT INTO my_table (...) RETURNING (id);
    SELECT count(\*) AS my_count FROM my_table;
    INSERT INTO historical (new_id, value_derived_from_count, now());
    COMMIT;

is difficult (or potentially impossible) to do transactionally using single HTTP queries. Sure, you can rewrite your queries to use single-statement queries if you're lucky, but for others that may take a lot of work. Keeping a transaction alive over WebSocket allows you to easily have transaction states that last longer than the lifetime of the first request, which allows for transactions of which state is processed in more than one place.

Sujan9• 4 years ago

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 the same transaction.

It's valid tradeoff to make to prefer a persistent connection to keep the overhead for multiple queries in a transaction as low as possible - which seems what Neon has done here.

rhyselsmore• 4 years ago

Just turn it into a single query using CTEs.

kelvich4• 4 years ago

Another angle here is compatibility. With our current driver one can use ordinary node-postgres package, as we can substitute TCP-related calls with WebSocket calls during the build time. With that it possible to use all the packages that do require node-postgres like Prisma, Zapatos, etc.

Sujan9• 4 years ago

Prisma does not actually use node-postgres, but a Rust PostgreSQL driver. Prisma will not be able to use the Neon serverless driver.

canadiantim• 4 years ago

Would it ever be possible to run neon on a mobile phone, offline?

nikita10• 4 years ago

We have some ideas of compiling Postgres to wasm and sync with the mothership in the cloud. But we haven’t funded the work. Check out electricsql they are looking at this problem.

thruflo• 4 years ago

Hey, link for the curious: https://electric-sql.com

Hybrid serverless <> local-first is the future. Neon in the client would be so cool.

vojtad• 4 years ago

Just for the recerence, it is possible to use Cloudflare Tunnel to connect to Postgres from Cloudflare Workers [1]. IIRC they also use WebSockets for communication between the Worker and the Tunnel.

[1] https://developers.cloudflare.com/workers/tutorials/query-po...

dboreham• 4 years ago

Hmm. Wouldn't this also be useful for browser-hosted application code that wants to talk to PG directly?

kelvich4• 4 years ago

Right, that is one of the use cases. Auth is tricky part in that setup -- in the browser user may change the query in arbitrary way. But there are some workarounds like obtaining JWT from 3rd party service and checking it via Row-Level Security policy in Postgres.

Edge-compatible Serverless Driver for Postgres

Related Stories