161–170 of 275 posts
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
I notice there is an Enterprise Edition, can you please specify which features are not open source? Do you predict new features you add will be ee licensed as a way to pay back your VC funders?
Two big ones: 1. Control plane to manage multi-node deployments; "works out of the box" experience to make PgDog easy to deploy and use 2. QoS (quality of service): automatically block bad queries from taking down the database Last but not least, you get SLA-backed support from us (up to P0). New features are broken down into two categories: 1. Sharding / running Postgres at scale: always open source. 2. Infra manage…
Earlier quoted context omitted.
Is a load balancer HA?
What happens when the load balancer fails?
> 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…
~1600 TPS is not 'high scale'.
"Why Us" => "I ran Postgres at Instacart, where we scaled the company 5x in April of 2020. The biggest problem we had was making Postgres serve 100,000s of grocery delivery orders per minute" Couldn't be a better why us :)
why did we switch to per minute? A modern quality enterprise SSD can do 35K +/- legit fsyncs per second.
Earlier quoted context omitted.
I worked at a company that had billions of views per year on a single big Postgres instance. Extremely read heavy with many queries needed for a page load. You can cache a lot of things.
Yes, but that's not a shopping cart, or a checkout workflow, nor a web store with heavy analytics.
No clue how a shopping cart or checkout flow would drastically increase database load. It should just be basic CRUD. Building a shopping cart is something every student makes. Pages in a web store can be cached relatively easily since items won't change often.
A primary DB with a few replicas and caching can go a really long way.
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.
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.
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.
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...
Instacard have released a public dataset[1] on their orders, so it should be even easier to verify this claim. From what I could find in some analysis[2] of this dataset around 100k orders per day and not per minute seems accurate. I assume they are referring to how many database requests they have due to customers orders or a similar metric and just worded it poorly. [1] https://www.kaggle.com/datasets/psparks/insta…