4 ms·

Their managed PostgreSQL offering also has fun quirks, such as that you have to connect using `username@db_name`, but your actual username in the database is st

Their managed PostgreSQL offering also has fun quirks, such as that you have to connect using `username@db_name`, but your actual username in the database is still just `username`, so any third party software needs to support using a different username to connect than it uses to perform user-related queries (they have some sort of application-level load balancer in front of it that uses `db_name` to route the connection).

bombcar 6y ago
This is ... something - wow - they couldn't just make the actual username "username@db_name"
- zanecodes 6y ago
  Nope. Their load balancer seems to strip the `@db_name` from connections, and anyway some software doesn't like having an @ in Postgres usernames (which is probably also a sign it's vulnerable to SQL injections)
llama052 6y ago
Oh that solution is a garbage fire. We hit the 4tb storage limit that they didn't tell us about on it when the documentation said 16tb. They told us we were on the older storage tier and that we needed to rebuild a huge analytics database on our time because they couldn't migrate us to a backend storage tier. So we had a database server that was in read only mode until we could migrate off of it. Then we had random restarts and outages with their proxy that handles all of the connections. Which is why you actually need the username@db-name, because without the @db-name it doesn't know where to route you, because the postgres connection string is actually just mapping to one IP that they manage for multiple databases! Fun trick is you can make your url anything that maps to the IP they use for their proxy and it'll take you to whatever the @db-name is in your connection string. Their solution to the random connections dropping for minutes at a time was to "implement retry logic" on our applications. Our solution was to migrate away from it.
thrixton 6y ago
We were well into implementation of a SaaS that relied on PG and used their cloud offering before we found that the latency was just abysmal. The best we could get was ~45ms using pgbench vs ~10ms local and ~18 using AWS Aurora. Their solution, wait for the flexible server offering which is not available in AUS but when tested in another region showed ~30ms so still not fit for purpose. We eventually had to switch to running PG in AKS which has its pros and cons. The funniest thing was, running Azure VM to AWS PG was faster than running Azure VM to Azure PG.

bombcar 6y ago

This is ... something - wow - they couldn't just make the actual username "username@db_name"

zanecodes 6y ago
Nope. Their load balancer seems to strip the `@db_name` from connections, and anyway some software doesn't like having an @ in Postgres usernames (which is probably also a sign it's vulnerable to SQL injections)

llama052 6y ago

Oh that solution is a garbage fire. We hit the 4tb storage limit that they didn't tell us about on it when the documentation said 16tb. They told us we were on the older storage tier and that we needed to rebuild a huge analytics database on our time because they couldn't migrate us to a backend storage tier. So we had a database server that was in read only mode until we could migrate off of it. Then we had random restarts and outages with their proxy that handles all of the connections. Which is why you actually need the username@db-name, because without the @db-name it doesn't know where to route you, because the postgres connection string is actually just mapping to one IP that they manage for multiple databases! Fun trick is you can make your url anything that maps to the IP they use for their proxy and it'll take you to whatever the @db-name is in your connection string. Their solution to the random connections dropping for minutes at a time was to "implement retry logic" on our applications. Our solution was to migrate away from it.

thrixton 6y ago

We were well into implementation of a SaaS that relied on PG and used their cloud offering before we found that the latency was just abysmal. The best we could get was ~45ms using pgbench vs ~10ms local and ~18 using AWS Aurora. Their solution, wait for the flexible server offering which is not available in AUS but when tested in another region showed ~30ms so still not fit for purpose. We eventually had to switch to running PG in AKS which has its pros and cons. The funniest thing was, running Azure VM to AWS PG was faster than running Azure VM to Azure PG.