[CtrlAltDelete51]

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

[rrdharan]

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.

[semiquaver]

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