Hacker News new | ask | show | jobs
by BowBun 1 day ago
I really wish they'd acknowledge the prior art and name that they've taken inspiration from - https://github.com/postgresml/pgcat

Don't pay a startup for your DB proxy, you should own that layer yourself inside of your infrastructure.

3 comments

The creator of pgdog is also the creator of pgcat, so I think they probably don't need to do this.
This reminds me of college. We had to cite our own papers from prior semesters or risk getting kicked out for plagiarism. I don't miss those days :)
I only just now realized

pg cat

pg dog

What's he going to name the next version?

pg emu ?

pg_pachy ?
pg mouse
I disagree, because now I am suspicious as to why there's a glaring omission like that. Never the mind looking at contribution timelines.
"it's not that deep" as the kids say.

In fact postgresML took naming heat because Postgres is right there in the name and they weren't affiliated with the brand. "pg" is just two letters. like WP-engine (literally the name as they say it is "double U P engine").

And a cat and a dog is fun.

don't think they're trying to get one over on you.

I don't think they're trying to get one over me, nor do I think it's _that deep_. One should simply acknowledge the prior projects that led to where you are today, even if they are your own. I 100% stand by my original statement and think that pgDog should mention that they're affiliated or a paid product on top of pgCat!
> you should own that layer yourself inside of your infrastructure

Unless you have millions of users, you don't really need this. It would be nice to have but its not a pressing need. So why invest into developing something that you only need once you are at massive scale? At this point you might as well switch away from Postgres because you'll surely have the manpower to do it.

Even with a proxy like PgDog the Postgres sharding story isn't solved. Resharding with logical replication is unlikely to work with databases which are already TBs in size. I never got it to catch up, I had to sync data at the filesystem level which is terrible. Tools like pg_repack also fall apart at scale.

For those that get to a point where a sharding proxy is required, switching databases is a very appealing solution.

And for those that are almost there, application side sharding is more flexible than building a query routing proxy.

Doesn’t PgDog also handle the sharding by proxying the writes? Maybe I missed something but I thought this is their value prop. It’s not just another PgBouncer.
From the docs you have to tell it which shard to access - it doesn't automagically rewrite your statements.
We also do that! But it's not well documented at the moment.
The founder is the author of both...