Hacker News new | past | comments | ask | show | jobs | submit
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.

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 ?

loading story #48487105
I disagree, because now I am suspicious as to why there's a glaring omission like that. Never the mind looking at contribution timelines.
loading story #48483361
> 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.

loading story #48483545
The founder is the author of both...