Earlier quoted context omitted.
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/…
Looks like a must-have thing that is also missing from planetscale is point-in-time recovery.
PlanetScale Insights: Advanced query monitoring
11–20 of 32 posts
Re: PlanetScale Insights: Advanced query monitoring
#12This 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
#13This 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
#14Their team is awesome, I requested a couple features in the CLI and they were there within a few hours. Support is responsive and the sales team was super helpful getting everything running and migrated.
Re: PlanetScale Insights: Advanced query monitoring
#15This 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…
I see the documentation and graphs, but can't find if PlanetScale provides a query interface into this data.
Single user systems do okay with reports like the ones I see in the link, where you can actually go in and drill-down into specific details in there.
It would much more awesome for the DBA style user if the reporting data was actually just loaded into another database/table with join schemas to query the data exactly as the report did. That of course, assumes the DBA is consultant type who is dropped in to fix cost overruns rather than the app developer going over their queries again.
In my last job, I built something of this sort (Hive has a protobuf SerDe + a special table named sys.query_data), so that I could connect up a CDSW Jupyter notebook and narrow down queries with a python program + a loop.
Of course, the queries themselves were also customer-paid queries, but it was much more flexible + a bunch of canned reports did most of the work when moving it across customers.
But before it was baked-in into Hive/CDW, it was actually a syslog parser which fed into a sqlite db which is almost exactly the same (but mostly intended at solving txn locking/conflict checking across hundreds of queries touching the same informatica audit log table).
Re: PlanetScale Insights: Advanced query monitoring
#16This 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…
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
I'll link to my other comment on the billing issue: 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. You're of course free to disagree — and I wish you all the best as you work to build something great in the future.
Re: PlanetScale Insights: Advanced query monitoring
#17Earlier 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…
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.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 I'…
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
Re: PlanetScale Insights: Advanced query monitoring
#18Earlier quoted context omitted.
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.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 I'…
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…
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.
Re: PlanetScale Insights: Advanced query monitoring
#19Earlier quoted context omitted.
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…
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 chargi…
anyway i gather the answer to my question is that no, there are no other examples of managed sql dbs that bill the way you do. my complaint is this is inherently not transparent because it violates user expectations. users try comparing to io based provders and fail to understand the pricing math comparison (on io pricing 1 read = many rows) or caching implications (on io pricing, cached rows dont count as io)
as for denigrating rds, look to your ceos past hn comments. i would link to it, but last time i did that i got flagged, despite it being a recent thread that i was directly participating in
Re: PlanetScale Insights: Advanced query monitoring
#20Earlier quoted context omitted.
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 chargi…
aurora serverless pricing is not based on cpu cycles . this is just not how ACUs actually work or scale or are priced, at all man anyway i gather the answer to my question is that no, there are no other examples of managed sql dbs that bill the way you do. my complaint is this is inherently not transparent because it violates user expectations. users try comparing to io based provders and fail to understand the prici…
According to AWS you're paying for chunks of CPU and memory on a per second basis: https://aws.amazon.com/rds/aurora/faqs/
It's hard to imagine that the CPU capacity is measured in anything other than CPU cycles (time slices of physical capacity) — in the same way it's hard to imagine that the memory capacity is measured in anything but bytes. But whatever, I don't care. It's cool, good for them. The point was... you don't think you're paying for reads of records that are cached? I give up, I fail to see how this can really be a good faith discussion.
I don't know how all other serverless database offerings do pricing. What difference does it make? They're all different. As a user, you want it to be based on your usage and to be fairly and reasonably priced while also being easily audited and predictable. Those are the key properties I would care about.
I honestly cannot see how you could be missing the point by this much and still be operating in good faith so I'll for real, for real stop. :-)