Live data from Hacker News

PgDog is funded and coming to a database near you

pgdog.dev

251–260 of 275 posts

Re: PgDog is funded and coming to a database near you

#251
post #177
post #171

Earlier quoted context omitted.

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!

Re: PgDog is funded and coming to a database near you

#252

We've run into so many issues with PgBouncer and Postgres that I wish we didn't have to deal with as a new growing company. Nice to see more options out there!

Like what? I've never had problems related to PgBouncer, but apparently we have different use cases. I'd love to hear where the rough edges are so I can avoid them, or at least plan for them in advance.

Re: PgDog is funded and coming to a database near you

#253
post #39
post #33

Earlier quoted context omitted.

Seconded. Coming from MySQL this is a huge regression that makes Postgres look like something from the 80s. I still wonder why this isn't seen as the absolutely highest priority.

I have not ran MySQL for some years but it at least used to have exactly the same issue. Upgrading a database with MySQL can take a long time if you have many tables. The main difference is only really that PostgreSQL does it with a separate tool, pg_upgrade, while MySQL does it as part of the main binary. For both MySQL and PostgreSQL you will need to use some kind of logical upgrades if you want no downtime.

No, the main difference is that MySQL bundles the code needed to interact with the old db version in the newer server binaries (effectively by not changing the on-disk binary format!) while pg_upgrade requires you to have both old and new installs living side-by-side to reuse logic/code from old binaries. It is a more bulletproof method and less susceptible to bugs and (upstream) developer errors, but is (or at least can be) harder for the sysadmin+dbadmin.

(For example, ports under FreeBSD doesn’t let you install multiple Postgres versions as they are marked as conflicting packages so installing one necessarily uninstalls the other. The saving grace here is that most (virtually all) FreeBSD installations have root on ZFS and you can employ ZFS snapshots (via the hidden .zfs folder) to access the old binaries after upgrading to the new postgres version, but not many people know this trick!)

Re: PgDog is funded and coming to a database near you

#254
post #159

Earlier quoted context omitted.

If you think 20TB "isn't that big" I want to know what size of DBs you're working with 0_0

It's big but it's not so big it wouldn't fit on SSD on one particularly beefy server (two for redundancy). Sharding this would be more about the transaction rate. Actually, sharding would always be about the transaction rate.

It doesn’t even remotely need to fit on one SSD with logical volume management (or RAID).

Re: PgDog is funded and coming to a database near you

#255

Earlier quoted context omitted.

According their 2026 Q1 filing they do about 90 million orders per quarter which is about 12 orders per second, 720 orders per minute. It might make 100k row level changes per minute, but that’s a different metric. https://www.sec.gov/Archives/edgar/data/1579091/000157909126...

it could be peak orders per second

Going from 720 average to 100,000s peak still doesn't sound realistic. especially as they operate in many timezones.

Re: PgDog is funded and coming to a database near you

#256
post #231

Earlier quoted context omitted.

The issue is if the DB layer fails your product is going to completely stop working. You’d need a ton of faith in these 3 people. Feels more like it would work better inside of a bigger organization. The QA tester in me is kinda risk adverse.

The source code is available for inspection as is the biographies of the people involved. They rely on the libraries that are part of Postgres itself to ensure they are parsing the SQL etc "correctly" (where "correct" means "the same as Postgres itself). Bigger organizations do not necessarily mean higher quality. What bigger organization is testing PostgreSQL itself? What are the relative quality measurements of Pos…

MariaDB has over 200 employees.

https://mariadb.com/about-us/careers/

Oracle's department that handles DBs probably has at least a few hundred.

3 people would be an ultra lean QA department for a product like this.

I'd have a hard time convincing my boss to go with PGDog over a more stable and tested solution.

This doesn't mean it's bad, just not ready yet

Re: PgDog is funded and coming to a database near you

#257
post #141

Earlier quoted context omitted.

CNPG is quite nice and robust but I'd still be a bit reluctant to stack PG on k8s for really big clusters just because k8s ecosystem moves quite quickly and there's lots of patching/maintenance/churn which means more PG failovers so depends on how well your workload handles that (they're normally only a few seconds)

Most K8s upgrades can happen independently of node reboots etc., you only need to update for OS updates really, but that would be true of anywhere you run PG, even RDS.

>but that would be true of anywhere you run PG, even RDS

It's a little easier to strip down userland if the machine is only running PG. Technically possible on k8s with distros like Talos, Bottlerocket, etc but you still have all the k8s deps on top of PG. It's also a little easier to do defense-in-depth on a dedicated PG machine which means you might have mitigating controls in place to skip security patches (minimal kernel modules, selinux)--possible on k8s but now you're fighting through a 2nd layer of configuration

RDS is a bit of a special case because you also have AWS curating and prioritizing updates. You can do that yourself but it's a bit of a time sink scrutinizing every upgrade to see if you _really_ need it. Our RDS instances tend to go 3+ months without restarts

Re: PgDog is funded and coming to a database near you

#258

> The reason DBs like Mongo or Dynamo exist is because Not quite. The reason "DBs" like those exist is purely due to fashion. Lets not kid ourselves into thinking they do anything better, save the exception of making data hard to access, which might be a project goal in some cases.

Dynamo definitely scales better than anything else at the tradeoff of not guaranteeing durability in the case of enough node failures and (like most distributed databases) not allowing interaction between different pieces of data.

> Tradeoff of not being able to query your data

Fixed it.

Re: PgDog is funded and coming to a database near you

#260

> The reason DBs like Mongo or Dynamo exist is because Postgres has a scaling problem. I've used Postgres at a few places and the #1 problem was always high availability, not scaling. One Postgres cluster could easily handle 100000 transactions per minute, but when a primary node went down it was a page and manually failing over to the spare then manually replacing the spare. The manual tooling was very finicky but a…

Patroni 1.0 was released in 2016, i.e ~10 years ago. https://github.com/patroni/patroni

Noted. If I ever have to administer a Postgres setup again I'll take a look. Thanks.
Post reply on HN