3 ms·
Curious about this line of thought because for most apps I reach for a RDBMS because I want strong data integrity and a data model that’s easy to reason about.
by programmarchy 6y ago
Curious about this line of thought because for most apps I reach for a RDBMS because I want strong data integrity and a data model that’s easy to reason about. Maybe you tend to work in different domains. Can you give an example of one of the projects better served by Bigtable?
- jeffbee 6y agoEverything? When the topic is operability it is easily shown that a database schema that you have to change atomically and the change becomes visible to all clients instantly is very incompatible with the ideas of rolling releases, rollback safety, zero maintenance windows, etc. If you can see that centralizing the schema doesn’t work well then you can also see that the schema doesn’t belong in the database at all, it belongs in the clients where it can be rolled forward and backward safely if you never try to change a field, only add them, which is a best practice anyway. After you’re onboard with this philosophy then I’m ready to sell you the fact that you don’t need joins, indexes, or transactions. If a giant complicated service like gmail doesn’t need any of those things then very likely that your thing doesn’t need them either.
- LoSboccacc 6y agothe intermediate layer between clients and the database is responsible to negotiate a protocol version, you shouldn't expose the storage model to the api layer, then schema versioning becomes a non problem.
- jeffbee 6y agoI don't think you can hide schemas that way in practice. At Dropbox I saw that they had an abstract storage service in front of MySQL but every aspect of the underlying schema leaked out through the API in some way.