Comment by codegeek
14 hours ago
"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 :)
Is 100k order per minute a lot? Even a single Postgres instance should serve that fine?
100k(s) orders per minute is several orders of magnitude more than realistic. Amazon does 20k orders per minute.
Instacart doesn't need "100,000s of grocery delivery orders per minute".
There must be some 0s added for the sake of the story.
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...
8 replies →
Amazon does 20k peak, or 20k average? Website visitor peaks could easily be two orders of magnitude higher traffic than average for a few minutes.
7 replies →
That doesn't necessarily mean _new_ orders per minute. Their app or website could poll for updates every 15 seconds
Could just be looking at the "orders" endpoint in their app which might also include incremental updates as shoppers get items from the store. It's a fairly ambiguous statement
It's orders, not queries. Who knows how many requests that actually takes.
One assumes they mean 100,000s (plural) concurrent users actively building carts
Is that still a lot? Feels like a single 64-core, 256GB RDS instance with some caching should handle that fine. RDS has instances up to 192-core and 768GB.
2 replies →
Average throughput is one thing, tail latency, quite another.
why did we switch to per minute? A modern quality enterprise SSD can do 35K +/- legit fsyncs per second.
Gives bigger numbers. But I agree per second is more honest.
I’ve always found Instacart to be extremely slow with giant latencies. Of course I don’t know if that’s due to Postgres or some other design flaw…
Legends