5 ms·

I still don't understand how you can work safely with this kind of pricing model. You pay $1.50 per 10 million rows inspected by the database. A relational dat

I still don't understand how you can work safely with this kind of pricing model. You pay $1.50 per 10 million rows inspected by the database. A relational database like MySQL has a query planner, so you're not fully in control over how exactly the database accesses your data. How many rows are read not only depends on your specific SQL query but also on the contents of the tables you read and the parameters supplied along with the query. A statistics update that triggers a bad query plan on a table with 10 million rows could cause a full table scan instead of retrieving a few rows using an index scan. Suddenly your query is a million times more expensive at $1.50 per query. Depending on how quickly and widely this scales, that could get very expensive very fast. 10 million rows is also not a lot for a relational database. I know my comparison now isn't fair as you get a lot more with the hosted version, but a quick and dirty experiment with Postgres and a small table of two ints and a text column with 10 million rows took ~1.5 seconds to query on my desktop, using only 1 CPU core. Translated into this pricing model that's something like $60 per minute.

siquick 5y ago
"Hey Infrastucture Finance Boss, we need a new database." "Thats cool, how much per month should we budget?" "$1.50 per 10 million rows inspected" "What? How much is that per month?" "TBC, and we won't know until we start using it" "RDS is $x per month so you're sticking with that"
jabo 5y ago
Their CEO mentioned that they’re working on an updated pricing model to address this issue, in another HN thread: https://news.ycombinator.com/item?id=29133026 https://news.ycombinator.com/item?id=29133026
mooreds 5y ago
See also https://briananglin.me/posts/spending-5k-to-learn-how-database-indexes-work/ https://briananglin.me/posts/spending-5k-to-learn-how-databa...
rustc 5y ago
Does MySQL (or PlanetScale) provide a way to input a query and get a lower/upper bound on the number of rows the query will "inspect" when run?
- CaveTech 5y ago
  Yes, through `EXPLAIN`.
- vishnugupta 5y ago
  MySQL’s “explain <query>” does exactly what you described and better. It shows indexes used, exact number of rows scanned etc. It’s the first thing I do when I suspect a query taking time. It’s a pity that not too many backend engineers know about it now a days.
  - fabian2k 5y ago
    That only explains the particular query plan chosen for the query at that time. This might vary depending on the table statistics, query parameter or moon phase if you're unlucky. It is a very important tool, but doesn't solve the problem here that in the end the database is in control and decides how many rows to read, not you.
    - unclebucknasty 5y ago
      >*might vary depending on the table statistics... This is a good point. You can control for some variables (like query parameters), via testing, however as table statistics change, so does query planning. For instance, your table gets bigger (or smaller) and MySQL chooses a different query plan. There's almost no way to completely predict pricing in all but the simplest of apps. Overall, the pricing model seems untenable.
  - rustc 5y ago
    > exact number of rows scanned etc I'm reading MySQL docs [1] and I can't figure out which value in the example output corresponds to the "exact number of rows scanned". > It’s a pity that not too many backend engineers know about it now a days. I use EXPLAIN with PostgreSQL when needed but mostly focus on the execution time, not the number of rows scanned (reading a large row could be orders of magnitude slower than reading a row in a JOIN table of two integers in a row based storage engine). [1] https://dev.mysql.com/doc/refman/8.0/en/explain.html https://dev.mysql.com/doc/refman/8.0/en/explain.html
deleted 5y ago
[deleted]
astockwell 5y ago
Their FAQ [1] clarifies this somewhat: > Every time a query retrieves a row from the database, it is counted as a row read. Every time a row is written to the database, it is counted as a row written. [1] https://planetscale.com/pricing https://planetscale.com/pricing (FAQ at bottom of the page)
- fabian2k 5y ago
  > Reads: Retrieving or inspecting rows during a query or mutation of any kind to your PlanetScale databases That's what the detailed pricing page says, which is somewhat different. The pricing is actually per row inspected, not per row returned to the client. So in aggregations you'd pay for every single row you aggregate. So I'd argue that the FAQ is actually misleading.
  - spookthesunset 5y ago
    So does that make an accidental full table scan an expensive operation from a billing standpoint? Like others say, the end user doesn’t have a lot of control over how the query planner does its magic. They do have control over what goes into and out of the system though. That being said things like Google BigQuery bill by compute time and data examined so I guess that works as long as the price per “unit” is on the order of millicents or something.
  - astockwell 5y ago
    Oof. Well that's not good.
danielrhodes 5y ago
This is sort of wait nails people with DynamoDB pricing. If you mess up your query, you end up scanning through tons of data, racking up the cost.
- dastbe 5y ago
  imo at least with dynamodb, its pretty straightforward what any given call is capable of doing, and you can get back capacity usage on every request to track. with these mysql/postgres compatible apis the actual query is abstracted as is its cost.
  - danielrhodes 5y ago
    Yeah the pricing model for SQL based queries is not optimal at all considering you don't control how the query optimizer will use the indexes, and (not trying to assign malice) they aren't very incentivized to improve it.
katzgrau 5y ago
Basically if you forget to query over an index and incur a full table scan, things are going to get very expensive, and it'll probably be a surprise since devs aren't going to bother checking charges run up.
aledalgrande 5y ago
Errors get expensive, but DDoS attacks could literally kill your business.

siquick 5y ago

"Hey Infrastucture Finance Boss, we need a new database." "Thats cool, how much per month should we budget?" "$1.50 per 10 million rows inspected" "What? How much is that per month?" "TBC, and we won't know until we start using it" "RDS is $x per month so you're sticking with that"

jabo 5y ago

Their CEO mentioned that they’re working on an updated pricing model to address this issue, in another HN thread: https://news.ycombinator.com/item?id=29133026 https://news.ycombinator.com/item?id=29133026

mooreds 5y ago

See also https://briananglin.me/posts/spending-5k-to-learn-how-database-indexes-work/ https://briananglin.me/posts/spending-5k-to-learn-how-databa...

rustc 5y ago

Does MySQL (or PlanetScale) provide a way to input a query and get a lower/upper bound on the number of rows the query will "inspect" when run?

CaveTech 5y ago
Yes, through `EXPLAIN`.
vishnugupta 5y ago
MySQL’s “explain <query>” does exactly what you described and better. It shows indexes used, exact number of rows scanned etc. It’s the first thing I do when I suspect a query taking time. It’s a pity that not too many backend engineers know about it now a days.
- fabian2k 5y ago
  That only explains the particular query plan chosen for the query at that time. This might vary depending on the table statistics, query parameter or moon phase if you're unlucky. It is a very important tool, but doesn't solve the problem here that in the end the database is in control and decides how many rows to read, not you.
  - unclebucknasty 5y ago
    >*might vary depending on the table statistics... This is a good point. You can control for some variables (like query parameters), via testing, however as table statistics change, so does query planning. For instance, your table gets bigger (or smaller) and MySQL chooses a different query plan. There's almost no way to completely predict pricing in all but the simplest of apps. Overall, the pricing model seems untenable.
- rustc 5y ago
  > exact number of rows scanned etc I'm reading MySQL docs [1] and I can't figure out which value in the example output corresponds to the "exact number of rows scanned". > It’s a pity that not too many backend engineers know about it now a days. I use EXPLAIN with PostgreSQL when needed but mostly focus on the execution time, not the number of rows scanned (reading a large row could be orders of magnitude slower than reading a row in a JOIN table of two integers in a row based storage engine). [1] https://dev.mysql.com/doc/refman/8.0/en/explain.html https://dev.mysql.com/doc/refman/8.0/en/explain.html

deleted 5y ago

[deleted]

astockwell 5y ago

Their FAQ [1] clarifies this somewhat: > Every time a query retrieves a row from the database, it is counted as a row read. Every time a row is written to the database, it is counted as a row written. [1] https://planetscale.com/pricing https://planetscale.com/pricing (FAQ at bottom of the page)

fabian2k 5y ago
> Reads: Retrieving or inspecting rows during a query or mutation of any kind to your PlanetScale databases That's what the detailed pricing page says, which is somewhat different. The pricing is actually per row inspected, not per row returned to the client. So in aggregations you'd pay for every single row you aggregate. So I'd argue that the FAQ is actually misleading.
- spookthesunset 5y ago
  So does that make an accidental full table scan an expensive operation from a billing standpoint? Like others say, the end user doesn’t have a lot of control over how the query planner does its magic. They do have control over what goes into and out of the system though. That being said things like Google BigQuery bill by compute time and data examined so I guess that works as long as the price per “unit” is on the order of millicents or something.
- astockwell 5y ago
  Oof. Well that's not good.

danielrhodes 5y ago

This is sort of wait nails people with DynamoDB pricing. If you mess up your query, you end up scanning through tons of data, racking up the cost.

dastbe 5y ago
imo at least with dynamodb, its pretty straightforward what any given call is capable of doing, and you can get back capacity usage on every request to track. with these mysql/postgres compatible apis the actual query is abstracted as is its cost.
- danielrhodes 5y ago
  Yeah the pricing model for SQL based queries is not optimal at all considering you don't control how the query optimizer will use the indexes, and (not trying to assign malice) they aren't very incentivized to improve it.

katzgrau 5y ago

Basically if you forget to query over an index and incur a full table scan, things are going to get very expensive, and it'll probably be a surprise since devs aren't going to bother checking charges run up.

aledalgrande 5y ago

Errors get expensive, but DDoS attacks could literally kill your business.