Live data from Hacker News

PlanetScale Insights: Advanced query monitoring

planetscale.com

31–32 of 32 posts

Re: PlanetScale Insights: Advanced query monitoring

#31

Earlier quoted context omitted.

tz setup is done with executing a single script. not surprising they could fix quickly. bigger surprise is they forgot to do this before youre support request. generally this is table stakes for managed DB this is fourth day in a row of planetscale ads^H^H^H blog posts being on hn front page. as i mentioned on yesterdays thread, innodb_rows_read is known to be buggy. regardless, by design it includes cached rows. ter…

"real cloud providers" most definitely charge based on rows read/written. Many startups / side projects choose the on-demand billing model because they don't want a fixed $x / mo when they don't need it. Some of them also have pre-provisioned options, and it seems likely that Planetscale will probably end up doing something similar. https://aws.amazon.com/dynamodb/pricing/ https://firebase.google.com/docs/firestore/p…

i was talking about managed sql databases

your first two examples are nosql. third example charges by data size processed, not by rows!

rows is weird metric since some tables have tiny rows, some have huge

Re: PlanetScale Insights: Advanced query monitoring

#32

Earlier quoted context omitted.

"real cloud providers" most definitely charge based on rows read/written. Many startups / side projects choose the on-demand billing model because they don't want a fixed $x / mo when they don't need it. Some of them also have pre-provisioned options, and it seems likely that Planetscale will probably end up doing something similar. https://aws.amazon.com/dynamodb/pricing/ https://firebase.google.com/docs/firestore/p…

i was talking about managed sql databases your first two examples are nosql. third example charges by data size processed, not by rows! rows is weird metric since some tables have tiny rows, some have huge

The point is that the market has shown there is a huge appetite for alternative database billing models other than a fixed cost per month. From my limited personal interactions, I'm aware of 10-20 developers who are using Planetscale in large part because of their billing model. They would have never considered a SQL database before because of the fixed cost.

Those nosql options (probably the most popular in the world) also have the issue that row sizes are different, and if you're super cost conscious, you can change your architecture to take advantage of it. For example with Planetscale, you could store a lot more in JSON columns instead of other tables to reduce costs if that was your primary objective.

Is your frustration that you'd like to use Planetscale or a managed Vitess, but you are worried about locking yourself into a pricing model that you don't think will work for you?

Post reply on HN