Our great sponsors
-
neon
Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, branching, and bottomless storage.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
postgres
Postgres.js - The Fastest full featured PostgreSQL client for Node.js, Deno, Bun and CloudFlare (by porsager)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I want to use this as a chance to bring attention to a GitHub issue that I think would help reduce friction for Neon:
https://github.com/neondatabase/neon/issues/4989
If the Neon driver were to allow us to easily pass in a localhost connection, the development and test experience would be easier. Perhaps Neon could swap to something like this internally: https://github.com/porsager/postgres.
Having run a local dev environment connected to Neon and tests connected to Neon got in our way of adoption. We'd prefer to develop and run tests against a regular Postgres localhost database.
To the PMs of Neon, put yourself in the shoes of a new developer thinking of giving Neon a try. What changes will I have to make to my code and my development workflow?
pg doesn't do too well with serverless, dead connections are left in the pool (or something)
https://github.com/brianc/node-postgres/issues/2112
Neon seems really great to me, but I wish I could easily run it locally via Kubernetes. I know there are some projects out there[0] but they are all supported by 3rd parties and things like branching and other features don't appear to be supported.
I'd love to be able to just use a helm chart to have Neon in my homelab.
[0] https://github.com/itsbalamurali/neon-operator
I want to use this as a chance to bring attention to a GitHub issue that I think would help reduce friction for Neon:
https://github.com/neondatabase/neon/issues/4989
If the Neon driver were to allow us to easily pass in a localhost connection, the development and test experience would be easier. Perhaps Neon could swap to something like this internally: https://github.com/porsager/postgres.
Having run a local dev environment connected to Neon and tests connected to Neon got in our way of adoption. We'd prefer to develop and run tests against a regular Postgres localhost database.
To the PMs of Neon, put yourself in the shoes of a new developer thinking of giving Neon a try. What changes will I have to make to my code and my development workflow?
Our fork of Postgres is located at https://github.com/neondatabase/postgres.