Live data from Hacker News

PgDog is funded and coming to a database near you

pgdog.dev

171–180 of 275 posts

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

#171
post #153

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

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

#172
Love PgDog. I don't need it honestly, but using it in my on-prem k8s because I heard about you in Postgres FM podcast randomly when I had nothing to listen to on a hike in the woods and it picked up my interest.

https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb

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

#173

Love PgDog. I don't need it honestly, but using it in my on-prem k8s because I heard about you in Postgres FM podcast randomly when I had nothing to listen to on a hike in the woods and it picked up my interest. https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb

Thanks!

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

#174
post #169

Earlier quoted context omitted.

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…

This data set was released years before the Covid hypergrowth phase which they are referring to.

That's fair as the Kaggle dataset[1] is from 2017. Even assuming orders scaled with revenue (which grew to $1.5B in 2020[2]), you'd only reach a few hundred orders/minute at the pandemic peak (which lines up with the calculation above via a different method).

So I still assume the original comment isn't referring to actual orders placed.

[1] https://www.kaggle.com/datasets/psparks/instacart-market-bas... [2] https://fortune.com/2022/05/18/what-to-know-instacart-ipo/

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

#175

Earlier quoted context omitted.

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...

And just like that you’ve done more due diligence than the VCs who just threw money at this.

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

#177
post #171

Earlier quoted context omitted.

The creator of pgdog is also the creator of pgcat, so I think they probably don't need to do this.

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.

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

#178
post #63
post #30

I'm curious how this might help with our biggest downtime-causer with postgres, which is major version upgrades. Poolers do a great job for failover and load balancing, but we consistently need ~10-20 minutes of downtime once or twice a year to do upgrades. Logical replication between old->new versions could probably help, but it would still require flipping everything over to the new cluster without partial writes o…

It's weird that PostgreSQL still doesn't have a proper, open source, general multi-master implementation. At this point i wonder if i'll ever see that.

Well, not officially, but there are solutions for that. Like BDR (or Postgres Distributed nowadays) by EDB.

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

#179
post #97

> With $5.5M from Basis Set, YC, Pioneer Fund and other great investors, we have years of runway, This is years of product development with a three person team. If Enterprise sales and support are a big part of your business plan it will suck up a lot more than that.

Presumably enterprise sales will bring in revenue on its own

Yes but the sales process for enterprise is often 9 months or more, and you have to have support coverage before it pays for itself.

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

#180

Earlier quoted context omitted.

Yes, but that's not a shopping cart, or a checkout workflow, nor a web store with heavy analytics.

It was one of the top real estate portals in the world. A lot of geolocation searches. New search every time someone moves the map. A ton of data sent to the client. Analytics in every page view. 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 ea…

The composition of the average transaction will be different in a shopping cart (lots of writes and updates) compared to your use case which sounds like it skewed read heavy. With Postgres it’s generally easier to scale reads because it doesn’t really matter which replica the query hits, as long as it contains the data it needs. Whereas write-heavy workloads route through a single-writer bottleneck.

There’s challenges scaling read-heavy workloads, for sure — but they’re generally more straight forward than scaling write-heavy workloads. You can get away with more dumb horizontal scaling than with writes.

Post reply on HN