It is not meaningless, but perhaps unclearly expressed.
There is a fundamental point the the argument: you can distribute a database without segregating it.
Three methods to building a 1M+ users webapp:
1. A centralized database, eg. PostgreSQL. Typically it has a single-writer beefy machine.
2. A decentralized newSQL. Tables are automatically sharded for writes, among a set of database-only servers. Typically offered as cloud: CosmosDB, Cloud Spanner, Aurora.
3. A distributed system segregated per app. Each user has a dedicated sqlite file.
The third option would be simpler to code for, since it won’t have substantial scaling issues.
It is also easier for a lambda-like platform to provide: load the sqlite corresponding to the authenticated user, and the lambda code, and execute the code in sandbox.
Although one negative aspect for the AWS of this world would be lack of lock-in. It is relatively easy to migrate to another cloud service, or to mix cloud services.
There is a fundamental point the the argument: you can distribute a database without segregating it.
Three methods to building a 1M+ users webapp:
1. A centralized database, eg. PostgreSQL. Typically it has a single-writer beefy machine.
2. A decentralized newSQL. Tables are automatically sharded for writes, among a set of database-only servers. Typically offered as cloud: CosmosDB, Cloud Spanner, Aurora.
3. A distributed system segregated per app. Each user has a dedicated sqlite file.
The third option would be simpler to code for, since it won’t have substantial scaling issues.
It is also easier for a lambda-like platform to provide: load the sqlite corresponding to the authenticated user, and the lambda code, and execute the code in sandbox.
Although one negative aspect for the AWS of this world would be lack of lock-in. It is relatively easy to migrate to another cloud service, or to mix cloud services.