I think its hard to draw a fine line on where this responsibility lies.

For example: for years, MongoDB took a lot of shit because by default it spins up unauthenticated. Hypothetically; devs take on the responsibility of adding a password. Realistically, shodan was able to index hundreds, maybe thousands, of databases across the internet with no authentication, some containing highly sensitive data.

Firestore is a great analogue to DynamoDB. Not perfect, but they solve a lot of the same problems in a lot of the same ways. Firestore automatically indexes every field in every document in every collection. Flat out. Everything is on an index. That single decision has reverberated to save tons of hours in compute time across all of their customers.

Is this expensive to do? I have no doubt; and its reflected in the cost of the two services. But believe it or not: Firebase isn't that much more expensive than DynamoDB ($0.25/million reads, versus $0.60/million).

> I think its hard to draw a fine line on where this responsibility lies.

I don't disagree, but I think there's consensus on what we consider footguns and what we consider features. Default on security footguns (like unauthenticated access to S3 buckets) should be changed. AWS has changed this. Default on performance features that cost customers money, and may be unused? We should limit those.

> That single decision has reverberated to save tons of hours in compute time across all of their customers.

It's hard to make a statement like this without data. How many of those fields are wasted disk space on a server somewhere under utilized? How much compute does indexing cost on those under utilized fields that should have been omitted?

You make the trade-offs on if you use Firestore or DynamoDB. They're different products, with different features.

I use Firestore and it won't let your perform multi-field filter and order operations without an explicit index.

When you try to do so, it spits out an error that tells you this operation requires an index and then provides a link to create the specific index.

I know it is a different database paradigm, but I think this is great "UX" design.

Firebase has a bunch of additional great features in this vein. It allows definition of min/max instances for Functions and if you set the min instances in the code, it will force a confirmation of price changes to prevent any unexpected charges. (GitHub Actions will fail, for example, until the price increase is confirmed via CLI.)

So i get OP. Yes, it is the responsibility of the engineer to know these things and make decisions, but the vendor can provide much better UX around these constraints.

There are two sides to this arrangment: devs who mostly don't have a choice over the tools they use vs. the trillion-dollar company that is building and documenting them. The notion that the devs have just as much culpability in how things end up as AWS is absurd.

> devs who mostly don't have a choice over the tools they use

I'm not going to assume that DynamoDB was forced upon them. I don't know. What I'm more sure about:

Developers have a choice in if they want to invest the time in understanding the tools they use, and learning about the tool's capabilities. In this specific case, we're not talking about a lot of time. 2-3 hours to read the documentation for a new database you're going to be building your business on top of.

What is your argument exactly?

I've personally seen developers "forced" into using DynamoDB because some AWS professional services consultant suggested it. You could argue the developers should've known better, but they had relatively little real world experience. The costs of Dynamo are relatively small compared to the development costs of using it when it's not a good fit.