5 ms·

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.

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. terrible thing to base billing on. real cloud providers base it on i/o instead since this is more reasonable metric of "use" planetscale's fork of mysql-server adds only a single commit, which exposes rows_read in an extra place. this from company that keeps talking about "building a database" https://github.com/planetscale/mysql-server https://github.com/planetscale/mysql-server

derekperkins 4y ago
"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://aws.amazon.com/dynamodb/pricing/ https://firebase.google.com/docs/firestore/pricing https://firebase.google.com/docs/firestore/pricing https://cloud.google.com/bigquery/pricing#on_demand_pricing https://cloud.google.com/bigquery/pricing#on_demand_pricing
- throwusawayus 4y ago
  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
  - derekperkins 4y ago
    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?
samlambert 4y ago
You think about us way more than is healthy.
- throwusawayus 4y ago
  this is your response to valid criticism of your pricing model and functionality? as ceo? really?
  - samlambert 4y ago
    We love feedback and criticism. You show up on all of our threads and take it way too far. I promise you, nothing you say to us will throw us off our vision and mission. You will only make yourself angrier and less happy by yelling at us on this website.
    - throwusawayus 4y ago
      if you think purpose of my comments is to “throw us off our vision and mission” you are mistaken
mattlord 4y ago
Installing the time zone tables on a single instance is certainly not hard: https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.html https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.ht... The trickier part is orchestrating the ongoing management of that across a large dynamic fleet. And in this case, it was much more than simply loading the tables but about using them to support importing databases into PlanetScale: https://github.com/vitessio/vitess/pull/10102 https://github.com/vitessio/vitess/pull/10102 I'll link to my other comment on the billing issue: https://news.ycombinator.com/item?id=31509240 https://news.ycombinator.com/item?id=31509240 We've had to do some other changes to our MySQL fork as well that will show up there, but we'd love to not have any patches! We'd love to keep the patch set minimal (just as Amazon certainly does with RDS and Aurora). And I would certainly argue that Vitess, which is what we build PlanetScale around, is a meaningful piece of technology that pairs with MySQL to make a great database: https://vitess.io https://vitess.io. You're of course free to disagree — and I wish you all the best as you work to build something great in the future.
- throwusawayus 4y ago
  what other managed sql DBs charge based on rows read, regardless of whether they are on-disk or in-memory? honest question. i am familiar with a number of managed mysql and postgres products, and none of them bill this way that i have ever seen and for the record, despite planetscale staffers repeatedly denigrating rds (your competitor) on hn, aurora’s patch set is not “minimal” i do think vitess is cool for what its worth. i just think your managed db product has bananas billing and also is horrendously over hyped, and your ceo’s responses to criticism are very reminiscant of theranos or wework’s responses to same
  - mattlord 4y ago
    I doubt that anyone would claim their billing metrics are perfect. If you find some specific workload that's actually cheaper on another serverless database offering then we'd love to hear about it (we strive for transparent, generous pricing). If you don't think that CPU usage based pricing — which is typical for serverless offerings and e.g. is what Aurora serverless uses in Aurora Capacity Units (ACUs) — is charging you for reads of cached data then I've got some bad news for you. :-) You're almost certainly being charged for reading the "row" from the network, write-ahead-logging for it and other ACID/MVCC related overhead, writing it to block device, reading it from the block device, reading it from memory, writing it to memory, sorting and comparing [pieces of] it, and writing it back to the network — all of these things take CPU cycles. I find this argument to be entirely missing the point. Pointing out that surely Amazon would like to keep their patch set to a minimum (there's a high cost in maintaining custom patches as you upgrade MySQL) is in no way implying that their patch set is small. Minimal means the minimum required for what you need, rather than being some point of pride. I'm certainly not on here bashing any other offerings. Between the two of us, I only see one person trolling / bashing. :-) With that, I will leave you to your opinions which you are of course free to have. Best of luck.

derekperkins 4y ago

"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://aws.amazon.com/dynamodb/pricing/ https://firebase.google.com/docs/firestore/pricing https://firebase.google.com/docs/firestore/pricing https://cloud.google.com/bigquery/pricing#on_demand_pricing https://cloud.google.com/bigquery/pricing#on_demand_pricing

throwusawayus 4y ago
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
- derekperkins 4y ago
  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?

samlambert 4y ago

You think about us way more than is healthy.

throwusawayus 4y ago
this is your response to valid criticism of your pricing model and functionality? as ceo? really?
- samlambert 4y ago
  We love feedback and criticism. You show up on all of our threads and take it way too far. I promise you, nothing you say to us will throw us off our vision and mission. You will only make yourself angrier and less happy by yelling at us on this website.
  - throwusawayus 4y ago
    if you think purpose of my comments is to “throw us off our vision and mission” you are mistaken

mattlord 4y ago

Installing the time zone tables on a single instance is certainly not hard: https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.html https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.ht... The trickier part is orchestrating the ongoing management of that across a large dynamic fleet. And in this case, it was much more than simply loading the tables but about using them to support importing databases into PlanetScale: https://github.com/vitessio/vitess/pull/10102 https://github.com/vitessio/vitess/pull/10102 I'll link to my other comment on the billing issue: https://news.ycombinator.com/item?id=31509240 https://news.ycombinator.com/item?id=31509240 We've had to do some other changes to our MySQL fork as well that will show up there, but we'd love to not have any patches! We'd love to keep the patch set minimal (just as Amazon certainly does with RDS and Aurora). And I would certainly argue that Vitess, which is what we build PlanetScale around, is a meaningful piece of technology that pairs with MySQL to make a great database: https://vitess.io https://vitess.io. You're of course free to disagree — and I wish you all the best as you work to build something great in the future.

throwusawayus 4y ago
what other managed sql DBs charge based on rows read, regardless of whether they are on-disk or in-memory? honest question. i am familiar with a number of managed mysql and postgres products, and none of them bill this way that i have ever seen and for the record, despite planetscale staffers repeatedly denigrating rds (your competitor) on hn, aurora’s patch set is not “minimal” i do think vitess is cool for what its worth. i just think your managed db product has bananas billing and also is horrendously over hyped, and your ceo’s responses to criticism are very reminiscant of theranos or wework’s responses to same
- mattlord 4y ago
  I doubt that anyone would claim their billing metrics are perfect. If you find some specific workload that's actually cheaper on another serverless database offering then we'd love to hear about it (we strive for transparent, generous pricing). If you don't think that CPU usage based pricing — which is typical for serverless offerings and e.g. is what Aurora serverless uses in Aurora Capacity Units (ACUs) — is charging you for reads of cached data then I've got some bad news for you. :-) You're almost certainly being charged for reading the "row" from the network, write-ahead-logging for it and other ACID/MVCC related overhead, writing it to block device, reading it from the block device, reading it from memory, writing it to memory, sorting and comparing [pieces of] it, and writing it back to the network — all of these things take CPU cycles. I find this argument to be entirely missing the point. Pointing out that surely Amazon would like to keep their patch set to a minimum (there's a high cost in maintaining custom patches as you upgrade MySQL) is in no way implying that their patch set is small. Minimal means the minimum required for what you need, rather than being some point of pride. I'm certainly not on here bashing any other offerings. Between the two of us, I only see one person trolling / bashing. :-) With that, I will leave you to your opinions which you are of course free to have. Best of luck.