Pulse error: Could not reach the specified datasource db url
New Pulse user here (experienced Prisma ORM user). Trying to connect to my local db via connection string:
postgresql://postgres:@localhost:5432/my_db?schema=public. At first I received an error that a password is required, so I stopped the server, added a pw of postgres to the database, changed connection string to postgresql://postgres:postgres@localhost:5432/my_db?schema=public, and then restarted the server. But still I continually get the "Could not reach specified db url" error. My NextJS app using the same connection string with Prisma ORM runs just fine, as does DBeaver for accessing the database. But for whatever reason, Pulse cannot connect. Any thoughts? Full error message below. I'm on PostgreSQL 16. I’m super eager to try Pulse, both locally and then ideally in an AWS/RDS production environment. Thanks.
Prisma Pulse could not reach the specified datasource db url. This could be caused by an incorrect datasource URL or database firewall rules, or certificate issues. This is probably not a problem with Prisma Pulse. The network error was: "server did not respond on the specified hostname and port. Proxy request failed."
27 Replies
👋 just trying to understand your setup. You have a DB running on your local machine at port 5432? Is this in a docker container or something similar?
DB running on local machine at port 5432. No Docker container. PostgreSQL 16 server running on Mac.
Thank you for responding @Jon Harrell! Hopefully we can get to the bottom of this.
Cool. And you’re trying to set up things through the Prisma Console, correct?
Correct.
By Prisma Console I assume you mean this:
Yup, exactly. In the area for “database connection string” are you putting in the connection string you mentioned above?
Yes
here's the exact string:
postgresql://postgres:postgres@localhost:5432/mydb?schema=public
as I noted, that exact string is pulled from my .env file which works perfectly well for my NextJS app with Prisma ORM
Let me know if you need any other details.So, the issue is that your connection string has
localhost. Pulse is looking for a server at localhost... which is the server (or servers) that Pulse is running on.
What you would need to do is have a public IP address that your DB is available at
In general, we would definitely recommend hosting the DB somewhere. AWS, Neon, Fly.io, etcHmm, then why do the docs show the example with localhost?
Oh.. do they? We should fix that. Could you link me to that doc?
https://console.prisma.io/workspaceId/appId/pulse/setup
i'd prefer to test with my database locally. is there a way to do that with ngrok?
the problem with AWS is that I have the db behind a security group. so i would need to know the IP address of Prisma to whitelist
Hmm, yes. I think setting up an ngrok tunnel would work.
And yeah, i think it would be helpful if the docs noted that the database must be in a publicly accessible location. it makes sense, but the localhost in the docs threw me off and got me excited that I could test locally:
Speaking of AWS though, how would you recommend running in production? Would users need to publicly expose their database just so Prisma can "talk" to it? If so, that would be a showstopper for us.
As of right now, yes, the DB needs to be publicly accessible. We're working on support for static IP addresses, but that's not available just yet.
That's too bad. I was hoping the Enable Pulse stuff was just to get an API key and that at that point the port could be closed and that the local @prisma/extension-pulse would handle the communication without needing to report back to your servers
No, communication is directed via our infrastructure. Same as with Accelerate
We don't use Accelerate - so this is all new to us.
OK, thanks for your help. It's back to the drawing board for us to create a semblance of real-time update triggers. Was really hoping Pulse would be the answer.
Sorry that it doesn't meet your specifications. I'm sure our team would love to know how we can get what you need. If you wouldn't mind, shoot an email to support {at} prisma {dot} io. We honestly love feedback, positive or negative.
You got it - will do. And thank you for taking time on a Friday night to help. Most appreciated. One final question if I might: do you know if Prisma ORM supports working with Postgres event triggers. Really we just need a way to take action when a particular table is updated.
I'm more than happy to help 🙂
We don't specifically have that, but is your DB updated just through Prisma ORM? If so, a client extension could probably help. If it's updated outside of the ORM then no, you'd need to add support to an existing issue we have.
Yes, updates are just through Prisma ORM, other than using raw sql query for one table where we need to store encrypted tokens and Prisma doesn't seem to support
pgp_sym_encrypt. But I don't quite follow what you mean by "a client extension". If you wouldn't mind elaborating, that would be most apprecaited! The use case we have is this: on webhook receipt, we want to store the webhook info into a table and reply back immediately with a 200 next response. And then have some way to fire off a series of actions once that particular table is updated. So the "trigger" we need is new entry created in 'webhook' table. Hopefully that makes sense.Sorry, in the middle of dinner so I'll reply in just a bit 🙂
oh interesting ... I think i see what you mean. I just did a bit of reading on a client extension, and it looks like I can modify a query operation on a given table. so perhaps something along these lines might do what we need:
essentially intercepting a
create to the webhooks table, fire/forget an async function for processing the webhook and meantime allowing the create to proceed as normal.Yes, exactly. The only issue to be aware of is what happens if the
processWebhook() call fails and the create succeeds, or vice versa, but I think that's similar in any implementation.understood and agreed. this is most helpful. thank you so much for pointing me in a good direction! you are awesome!!!
:heart: thank you very much