Would it ever be possible to run neon on a mobile phone, offline?
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.
Edge-compatible Serverless Driver for Postgres
11–20 of 46 posts
Re: Edge-compatible Serverless Driver for Postgres
#12I’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
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?
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.
Re: Edge-compatible Serverless Driver for Postgres
#13Earlier quoted context omitted.
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.
Storage is multi tenant and bottomless. Unused storage spills to S3 and is cheaper. We pass savings to our users
I think you're telling me the answer but I amn't sure.
Suppose I use 10TB of storage, and then later I delete all but 100GB of storage. Will I be paying for 10TB or 100GB?
Re: Edge-compatible Serverless Driver for Postgres
#14Earlier quoted context omitted.
Storage is multi tenant and bottomless. Unused storage spills to S3 and is cheaper. We pass savings to our users
I think you're telling me the answer but I amn't sure. Suppose I use 10TB of storage, and then later I delete all but 100GB of storage. Will I be paying for 10TB or 100GB?
100GB
Re: Edge-compatible Serverless Driver for Postgres
#15Earlier quoted context omitted.
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?
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.
Yes. Also it was an easier thing to do and ship quickly. We are going to get very tight on latencies and if that would require building it into Postgres we will do so
Re: Edge-compatible Serverless Driver for Postgres
#16The "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 H…
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.
Re: Edge-compatible Serverless Driver for Postgres
#17Would it ever be possible to run neon on a mobile phone, offline?
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.
Hey, link for the curious: https://electric-sql.com
Hybrid serverless local-first is the future. Neon in the client would be so cool.
Re: Edge-compatible Serverless Driver for Postgres
#18The "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 H…
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;
Re: Edge-compatible Serverless Driver for Postgres
#19The "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 H…
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…
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?
Re: Edge-compatible Serverless Driver for Postgres
#20The "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 H…
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 y…
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.