Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PlanetScale Insights: Advanced query monitoring

planetscale.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: PlanetScale Insights: Advanced query monitoring

#21

Post by throwusawayus »

mattlord wrote: post #20
throwusawayus wrote: post #19

Earlier quoted context omitted.

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…

It's fairly difficult to find actual details on ACUs and how it all works, the best I found after spending significant time looking was things like: https://www.jeremydaly.com/aurora-serverless-the-good-the-ba... 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 cy…

you just are not understanding my point, that does not mean i am acting in bad faith! jeez

i originally said pricing for other managed sql dbs, not specifically “serverless” ones. we both know that is just a marketing term anyway

with ACUs the point is you configure min and max, and your cluster scales up/down based on a cpu utilization threshold. so, sure reading from memory uses cpu cycles — but a large cached read is incredibly unlikely to bump you over a scaling threshold which affects your bill, unless you’re doing some huge heavy sort operations

another key point is aurora serverless v2 does not scale down to 0 acu. you are always paying a predictable small amount for your base cpu and ram. minor increases in cpu usage literally do not impact your bill at all, which is why i do not believe your argument makes sense regarding cached reads.

edit to add: the reason this matters for monetary cost of ELT/ETL is it often involves very large reads. if your jobs only extract recent/changed data, this will very likely be in buffer pool, and cost way less with io pricing than with your row based pricing. clear?

Re: PlanetScale Insights: Advanced query monitoring

#22

Post by derekperkins »

datalopers wrote: post #13
Scarbutt wrote: post #3

Earlier quoted context omitted.

The lack of FKs is a turn off for most apps.

Database-enforced FKs are an overrated crutch anyway. Apply the third normal form, utilize transactions correctly, and you won't ever need them.

Strongly disagree. They allow you to declaratively say what data is allowed. No system where devs write code is going to be infallible, no matter how much people want it to be true. Show me a database without FKs and I'll show you a database with orphaned rows and insistent data.

That being said, depending on the data you're working with, you may be fine with that trade-off.

Re: PlanetScale Insights: Advanced query monitoring

#23

Post by derekperkins »

Scarbutt wrote: post #3
joshstrange wrote: post #2

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

Vitess, the underlying tech, only disallows FKs if you use online schema changes. They have to be on the same logical shard, and it just uses standard MySQL FKs. Hopefully Planetscale allows them in the future, as long as you're willing to give up OSC. We've been running Vitess for years with that trade-off and it works great.

Re: PlanetScale Insights: Advanced query monitoring

#24

Post by derekperkins »

KwisaksHaderach wrote: post #11
ithrow wrote: post #5

Earlier quoted context omitted.

Looks like a must-have thing that is also missing from planetscale is point-in-time recovery.

PiTR is like the primary reason for us using a managed DB, it's indeed a weird and fatal omission from a managed DB offering.

Vitess supports PITR, so I'm sure it'll land in Planetscale sooner or later

Re: PlanetScale Insights: Advanced query monitoring

#25

Post by vvern »

derekperkins wrote: post #23
Scarbutt wrote: post #3

Earlier quoted context omitted.

The lack of FKs is a turn off for most apps.

Vitess, the underlying tech, only disallows FKs if you use online schema changes. They have to be on the same logical shard, and it just uses standard MySQL FKs. Hopefully Planetscale allows them in the future, as long as you're willing to give up OSC. We've been running Vitess for years with that trade-off and it works great.

> They have to be on the same logical shard

This is a pretty major limitation. Part of the reason to use Vitess is to scale out. It is often very valuable to have a small number of root elements in a star schema and to have foreign keys which ladder up to them.

Re: PlanetScale Insights: Advanced query monitoring

#26

Post by [deleted] »

derekperkins wrote: post #22
datalopers wrote: post #13

Earlier quoted context omitted.

Database-enforced FKs are an overrated crutch anyway. Apply the third normal form, utilize transactions correctly, and you won't ever need them.

Strongly disagree. They allow you to declaratively say what data is allowed. No system where devs write code is going to be infallible, no matter how much people want it to be true. Show me a database without FKs and I'll show you a database with orphaned rows and insistent data. That being said, depending on the data you're working with, you may be fine with that trade-off.

[deleted]

Re: PlanetScale Insights: Advanced query monitoring

#27

Post by vvern »

datalopers wrote: post #13
Scarbutt wrote: post #3

Earlier quoted context omitted.

The lack of FKs is a turn off for most apps.

Database-enforced FKs are an overrated crutch anyway. Apply the third normal form, utilize transactions correctly, and you won't ever need them.

> utilize transactions correctly

This seems hard to do in Vitess or PlanetScale given the technically READ UNCOMMITTED isolation [1] when cross shard, and, in scaled deployments, will still require experimental 2PC [2] cross shard transaction. So, like, yeah, if you had serializable isolation, then transactions might save you so long as your code isn't buggy, but, literally the reason the system doesn't implement them is because it doesn't have isolated transactions.

[1]: https://news.ycombinator.com/item?id=22170416#22177783 [2]: https://vitess.io/docs/13.0/reference/features/two-phase-com...

Re: PlanetScale Insights: Advanced query monitoring

#28

Post by derekperkins »

vvern wrote: post #25
derekperkins wrote: post #23

Earlier quoted context omitted.

Vitess, the underlying tech, only disallows FKs if you use online schema changes. They have to be on the same logical shard, and it just uses standard MySQL FKs. Hopefully Planetscale allows them in the future, as long as you're willing to give up OSC. We've been running Vitess for years with that trade-off and it works great.

> They have to be on the same logical shard This is a pretty major limitation. Part of the reason to use Vitess is to scale out. It is often very valuable to have a small number of root elements in a star schema and to have foreign keys which ladder up to them.

That's a different problem also solvable with Vitess. For those smaller tables, you can define them as a reference table, then have the same rows on every shard, so you can continue to have FKs to all of those.

https://vitess.io/docs/13.0/user-guides/vschema-guide/advanc...

When you're choosing your sharding keys, you want to design it where the bulk of your operations happen on a single shard, often a tenant/customer id. That guarantees that all customer data lands on a single shard, with FKs across every table you want.

We're running on ~40 shards across 6 keyspaces, and there are very few cases where we can't use FKs.

Re: PlanetScale Insights: Advanced query monitoring

#29

Post by derekperkins »

vvern wrote: post #27
datalopers wrote: post #13

Earlier quoted context omitted.

Database-enforced FKs are an overrated crutch anyway. Apply the third normal form, utilize transactions correctly, and you won't ever need them.

> utilize transactions correctly This seems hard to do in Vitess or PlanetScale given the technically READ UNCOMMITTED isolation [1] when cross shard, and, in scaled deployments, will still require experimental 2PC [2] cross shard transaction. So, like, yeah, if you had serializable isolation, then transactions might save you so long as your code isn't buggy, but, literally the reason the system doesn't implement the…

In a production environment with well architected sharding, that rarely comes up in practice. It will be designed so that 99% of your operations happen on a single shard, both for performance and for transactional guarantees. That's often a customer/tenant id, and it's rare in practice that you will be performing cross-customer transactions.

Re: PlanetScale Insights: Advanced query monitoring

#30

Post by derekperkins »

throwusawayus wrote: post #6
joshstrange wrote: post #2

This 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…

"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/pricing

https://cloud.google.com/bigquery/pricing#on_demand_pricing

Post reply on HN