If they are running on AWS (which it looks like they are), they aren’t going to be able to undercut AWS. For a retail user who doesn’t want to commit to RIs or have enough volume for an EDP, sure PS can be cheaper.
The value I found is being able to do multi-region read replicas with no compute overhead for lower traffic geos.
I like the idea of PS and have toyed around with the idea of migrating to it but there are some glaring issues I don’t want to deal with:
- no native way to export backups and avoid vendor lock in (or pay for the row reads to generate regular backups)
- contradictory cost model. Their pricing page reads “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.” while their docs state “Rows read is a measure of the work that the database engine does, not a measure of the number of rows returned. Every row read from a table during execution adds to the rows read count, regardless of how many rows are returned.”
It’s very common for scale-out architectures to read more data than is ultimately returned, because the former is pulled from individual shards and then some centralized filtering / post processing is applied in some API middleware layer.
Trying to fix that by pushing down more of the query/execution is sometimes but not always feasible or practical.
(responding to GP) “Full table scans are expensive” is a better way to reframe the pricing model (at least before this pricing change). The distinction is between rows _examined_ vs rows _returned to a db client_. Even the latter is a tricky concept with vitess since it’s a routing/sharding system that sits on top of vanilla MySQL instances.
Comments
If they are running on AWS (which it looks like they are), they aren’t going to be able to undercut AWS. For a retail user who doesn’t want to commit to RIs or have enough volume for an EDP, sure PS can be cheaper.
The value I found is being able to do multi-region read replicas with no compute overhead for lower traffic geos.
I like the idea of PS and have toyed around with the idea of migrating to it but there are some glaring issues I don’t want to deal with:
- no native way to export backups and avoid vendor lock in (or pay for the row reads to generate regular backups)
- contradictory cost model. Their pricing page reads “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.” while their docs state “Rows read is a measure of the work that the database engine does, not a measure of the number of rows returned. Every row read from a table during execution adds to the rows read count, regardless of how many rows are returned.”
That’s not contradictory?
It’s very common for scale-out architectures to read more data than is ultimately returned, because the former is pulled from individual shards and then some centralized filtering / post processing is applied in some API middleware layer.
Trying to fix that by pushing down more of the query/execution is sometimes but not always feasible or practical.
(responding to GP) “Full table scans are expensive” is a better way to reframe the pricing model (at least before this pricing change). The distinction is between rows _examined_ vs rows _returned to a db client_. Even the latter is a tricky concept with vitess since it’s a routing/sharding system that sits on top of vanilla MySQL instances.