4 ms·
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 unaut
by 015a 4y ago
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).
- ctvo 4y ago> 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.