PlanetScale Insights: Advanced query monitoring
planetscale.com
PlanetScale Insights: Advanced query monitoring
1–10 of 32 posts
Re: PlanetScale Insights: Advanced query monitoring
#2So far my usage has been minuscule in comparison to the PS limits. That said, I had been hoping for better tools to identify "problem queries" early instead of just when the billing cycle comes up and so I'm happy to see work in that direction.
Just a random anecdote about PlanetScale:
A few weeks ago I realized their databases did not have the timezone database loaded into them and it wasn't something I could do myself. I needed this so I could do `CONVERT_TZ` to convert from UTC to the user's TZ (for report aggregation). I reached out to support and in about a week they had added it to their roadmap, shipped it, and turned on the new feature for my DBs. They have been a joy to work with so far and I encourage you give them a shot, especially if you are on Aurora Serverless (V1 or V2).
Re: PlanetScale Insights: Advanced query monitoring
#3This is a great addition to the PlanetScale offerings. One of the scariest things with PS was "I have no clue how many rows are read/written" and usage-based plans are hard if you don't think in the terms they they charge in. It was just a metric I had never tracked or done much work on. That might be telling of myself and my DB management skillset (or lack there of). So far my usage has been minuscule in comparison…
Re: PlanetScale Insights: Advanced query monitoring
#4This is a great addition to the PlanetScale offerings. One of the scariest things with PS was "I have no clue how many rows are read/written" and usage-based plans are hard if you don't think in the terms they they charge in. It was just a metric I had never tracked or done much work on. That might be telling of myself and my DB management skillset (or lack there of). So far my usage has been minuscule in comparison…
The lack of FKs is a turn off for most apps.
Re: PlanetScale Insights: Advanced query monitoring
#5Earlier quoted context omitted.
The lack of FKs is a turn off for most apps.
I can understand that, for myself I don't miss them. An index on the column is just fine for me and personally I prefer to manage that in the application layer (I know I'm probably not in the majority). Lack of FKs is what allows for their scaling technique (using Vitess) from what I understand. I'll say for my use it's not been an issue but I do understand that migrating an app that does need/use them might be hard/…
Re: PlanetScale Insights: Advanced query monitoring
#6This is a great addition to the PlanetScale offerings. One of the scariest things with PS was "I have no clue how many rows are read/written" and usage-based plans are hard if you don't think in the terms they they charge in. It was just a metric I had never tracked or done much work on. That might be telling of myself and my DB management skillset (or lack there of). So far my usage has been minuscule in comparison…
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
Re: PlanetScale Insights: Advanced query monitoring
#7This is a great addition to the PlanetScale offerings. One of the scariest things with PS was "I have no clue how many rows are read/written" and usage-based plans are hard if you don't think in the terms they they charge in. It was just a metric I had never tracked or done much work on. That might be telling of myself and my DB management skillset (or lack there of). So far my usage has been minuscule in comparison…
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…
Re: PlanetScale Insights: Advanced query monitoring
#8Earlier 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…
You think about us way more than is healthy.
Re: PlanetScale Insights: Advanced query monitoring
#9Earlier quoted context omitted.
You think about us way more than is healthy.
this is your response to valid criticism of your pricing model and functionality? as ceo? really?
Re: PlanetScale Insights: Advanced query monitoring
#10Earlier quoted context omitted.
this is your response to valid criticism of your pricing model and functionality? as ceo? really?
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.