An elegant concept. If your schema is good, this works. Even if it sucks, it will probably still work.<p>We don't have the discipline to go all the way, but we are pretty close conceptually - the UI/logic layer is still done in code. 100% of the data lives in exactly 1 SQL database, and all of our products are expected to communicate by way of the schema for integration purposes. There are no API contracts or JSON/gRPC-serialized things anymore. The schema is the contract and all application state transitions must pass through the transaction log.<p>One database can scale like bananas with the technology we have today. There's really no reason to optimize prematurely on this one. Even if your business is so data intensive that one SQL database won't work (doubtful), then you still need a place to store <i>metadata</i> regarding the data that presumably won't fit so that it can be retrieved by other means. Once we get down it - If you combine a SQL database w/ some blob storage provider (i.e. S3), what excuse remains from a purely data/information theory perspective?<p>I think the dark secret truth that underlies why we don't see more of this architecture is simply because it is boring and "too easy". There's not a lot of opportunity to look like a smart-ass in front of others when we are mostly talking about glorified excel documents.