4 ms·
I really wish they'd acknowledge the prior art and name that they've taken inspiration from - https://github.com/postgresml/pgcat https://github.com/postgresml/
by BowBun 4mo ago
I really wish they'd acknowledge the prior art and name that they've taken inspiration from - https://github.com/postgresml/pgcat https://github.com/postgresml/pgcat
Don't pay a startup for your DB proxy, you should own that layer yourself inside of your infrastructure.
- xyzzy_plugh 4mo agoThe creator of pgdog is also the creator of pgcat, so I think they probably don't need to do this.
- levkk 4mo agoThis 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 :)
- BowBun 4mo agoI disagree, because now I am suspicious as to why there's a glaring omission like that. Never the mind looking at contribution timelines.
- apsurd 4mo ago"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.
- BowBun 4mo agoI 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!
- jmchuster 4mo agoI only just now realized pg cat pg dog What's he going to name the next version? pg emu ?
- re-thc 4mo agopg mouse
- johnthescott 4mo agopg_pachy ?
- dujuku 4mo agoThe founder is the author of both...
- aeyes 4mo ago> 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.
- chatmasta 4mo agoDoesn’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.