(Not that I want to gazump @Sam here - he was probably first in line in getting help.)
(Not that I want to gazump @Sam here - he was probably first in line in getting help.)
SIt's ok haha
KThe local Hyperdrive is really just talking to your localConnectionString with the TCP sockets API, it isn’t any different to if you passed it in your code directly rather than the Hyperdrive binding.
Does your pg_hba.conf dictate a specific auth method or options (like ssl)? It sounds like Hyperdrive supports a set of features that the direct connection might not.
Does your pg_hba.conf dictate a specific auth method or options (like ssl)? It sounds like Hyperdrive supports a set of features that the direct connection might not.
MYeah I assumed local mode bypassed Hyperdrive completely and just connected traditionally, without Hyperdrive. As for pg_hba.conf, I'm afraid this is where my expertise ends. I don't literally have that file - I just have a Heroku-hosted DB that I can connect to publicly (i.e. there's no IP whitelist or anything like that). Non-Wrangler apps running on my machine can talk to it, but the Wrangler app throws the PG error.
KDo you have the full FATAL error from the Worker? Feel free to redact the IP/username
KIf it says ssl off, Heroku requires SSL for all connections
MI connect via:
This is taken verbatim from an app that connects to the DB fine.
Full error output is:
This is taken verbatim from an app that connects to the DB fine.
Full error output is:
KThis is node-postgres I assume
MSorry yes
KTry adding ?sslmode=require to your local conn. string
MRight after the DB name? Same deal, unfortunately.
M(Disappearing for dinner but will check back later. Really appreciate the help, whether it gets solved or not!)
KDoes the error still say no encryption?
KI guess “no encryption” could also refer to the password. I.E scram-sha-256
MWhat version of
node-postgresYes the error still says no encryption.
node-postgrespg
MHyperdrive supports PostgreSQL and PostgreSQL-compatible databases, popular drivers and Object Relational Mapper (ORM) libraries that use those …
MGood spot, and have updated PG, but still the same error
M
MThe error you're getting is on the Heroku side - e.g. https://stackoverflow.com/questions/60048669/heroku-postgres-psql-fatal-no-pg-hba-conf-entry-for-host
Stack Overflow
There are a number of Heroku CLI Postgres commands that all return the same error. For example:
$ heroku pg:bloat
psql: FATAL: no pg_hba.conf entry for host "...", user "...", database "...", SSL...
$ heroku pg:bloat
psql: FATAL: no pg_hba.conf entry for host "...", user "...", database "...", SSL...
Mpg_hba.conf
Btrying to restrict access to my database to CF ips only but getting an error when trying to setup hyperdrive
B
KHyperdrive doesn’t use the public CF IPs.
Bah 
Bso no good way to block non CF access via firewall rn?
KCorrect, nothing yet
HWouldn't an ASN-level block work?
MNo, and we generally don't recommend that. An IP (or AS) filter doesn't stop anyone else from creating a Hyperdrive configuration and connecting to your origin database.
M(An AS level filter will also not work here, so please don't try it)
SWithin wrangler.toml, localConnectionString is now required. But is there any way to mask the value of this string when uploading to Github? I hate that it's required now, since we can't protect Postgres accounts by IP restrictions.
MIt should not be required. It’s only used for local testing. You can leave it empty. My Hyperdrive test project does not set it.
SI can’t start my project if I don’t give the wrangler file a local connection string. And if I keep the string empty, it also doesn’t start
MThat’s local — with
wrangler devYes, but it should not be required. I want to put my connection string in .dev.vars. This wont show up in Github.
Shello hyperdrive friends
Si was hoping to hang out until mysql is supported, we're excited
AThe hyperdrive page shows nothing in Traditional Chinese, but it works in English.
C
we're seeing what we believe to be inconsistent caching in Hyperdrivewhen repeatedly sending a relatively simple SQL query (looks just like
SELECT data FROM my_table WHERE primary_key = 1234;dataIt also seems to go in runs - we'll get correct responses for a minute, then incorrect responses for a minute, and so on. I've only ever been able to reproduce this when going through Hyperdrive (with a minute TTL cache), never when connecting directly to the DB
Unfortunately we rely pretty heavily on Hyperdrive caching to not overload the origin DB so disabling cache isn't an option here
GAt the moment there's a mTLS to TLS issue right? Kind of tired of using mongoDB data api. Any plans to fix the driver issue for workers?
MWe’re working with Mongo. Their driver is not simple to run in a (proper) serverless environment
MWhat’s your account ID & hyperdrive config ID?
CAccount ID:
Hyperdrive ID:
cfd355bcff7e6af6838743ae944184b0Hyperdrive ID:
0bbf89fd8f5544b4a313f26006174018
AI have a question about how hyperdrive works that I couldn't find an answer to in the blog or docs:
Let's say a customer is in Singapore, the CF worker is Singapore, and the database is in US-East1.
Is there any difference in the network path (and subsequent latency) for our Singapore CF worker using hyperdrive vs using something like the Neon serverless driver? Is it using CF peering connections or something else that would make the latency lower when using CF?
Let's say a customer is in Singapore, the CF worker is Singapore, and the database is in US-East1.
Is there any difference in the network path (and subsequent latency) for our Singapore CF worker using hyperdrive vs using something like the Neon serverless driver? Is it using CF peering connections or something else that would make the latency lower when using CF?
CAs far as I understand (I don't work for CF or anything), Hyperdrive will do the PG handshake at the edge right near your worker (with very low latency), and Neon serverless will do the PG handshake at the origin. The PG handshake is like 7 (this is a guess) round trips, so the connection establish time is significantly lower
Athanks Colin - yeah that makes sense. I am just wondering if there is also any material difference in the path that the bits take as they route around the globe.
Honestly no idea if it would even make a difference, but it would make sense to me if this route:
was faster than...
Honestly no idea if it would even make a difference, but it would make sense to me if this route:
was faster than...
CAs far as I'm aware the packets do go over the public Internet right now, not CF fiber
CWanted to add onto this. We created two Hyperdrives, one with cache, one without. The one with cache consistently has this issue, the one without cache never does. Happy to share exact queries + dev DB to reproduce if someone from CF is interested in taking a look 
AIf you have a schema and queries that reproduce this that you're comfortable sharing, definitely please do!