[fabian2k]

I still don't see how this pricing model is usable in a database with a query planner. The user is not in control over the query plan, the database is. This is a recipe for disaster, and I'd never feel comfortable with this. Even with good understanding of how the database works there is pretty much no way to ensure that the database doesn't do some suprising full table scans.

[dasil003]

Many young founders won't have the experience or the patience to really understand this, and in practice most won't have the scale to really feel the pain anyway. The ones that do will be worth so much they can negotiate custom contracts. Such is the market for pickaxes created by easy VC money.

[pjscott]

My big problem with SQL is that I want to do the query planning. Sure, the database can often do a better job -- but I want to be able to guarantee upper bounds on things, damn it! I've seen so many weird edge-case performance problems that boiled down to poor query plans. Things will be fast most of the time and then, suddenly, the database will look at its stats and decide to do a full table scan, and then everything goes straight to hell and stays there for too many milliseconds.

If I ever cross paths with a database, I'll spit on its shadow.

[azurelake]

MySQL has query hints: https://mariadb.com/kb/en/index-hints-how-to-force-query-pla...

[mirntyfirty]

True, even with tuned indices table scans are pretty frequent and perhaps one would want a slower but cheaper query. It’d be quite stressful to have to worry about query plans executed because they can vary quite a bit across very similar queries and be nudged towards more expensive queries by development teams.

[fabian2k]

If your application allows somewhat flexible queries this might also create potential Denial of Money attacks, which I personally find scarier than plain old Denial of Service. I mean that's always a risk with this type of pricing, but the particulars of a relational database with a query planner makes this a lot more dangerous.

[rockwotj]

This is why Google Cloud Firestore/Data store charges for rows returned, but the caveat is you can't do stuff like aggregations as the cost just doesn't work out