|
|
|
|
|
by marcua
22 hours ago
|
|
(Author here) Thank you for pushing on this. Some clarifications that might help you see this as more practical than your initial impression:
* I totally agree that databases require maintenance, HA, etc. My argument is not that someone running a database magically doesn't have to do these things, but rather that the person running the database doesn't have to be the person running the app. In the video attached to the blog post, you can see that separation in action: marcua.net hosts the Todos app, but thedata.zone hosts an ayb [1] database instance. As the owner of thedata.zone, it's my responsibility to configure the database for stuff like offsite snapshot-based backups (which I've done).
* Schema migrations are an application-level concern, and are no more or less challenging in the model I'm proposing. As a convenience, in the ayb.js client I open sourced, I add some utilities for forward-only migrations to make it a little easier for application developers who build around ayb to have migrations fire at the right moment in their application's lifecycle.
* Authorization is definitely not assumed to be one database to many apps. In the video, look for how the user already has a streaks.sqlite database (for storing streak data) and creates a new todos.sqlite database for storing their to-dos. Thank you for engaging on this! I look forward to hearing your thoughts! [1] https://github.com/marcua/ayb |
|
From practical standpoint you have to consider that the traditional use case for databases has been N:1 (n application instances, 1 DB) and you are inverting this.
There might be some unique B2C scenario where this makes business sense, however if you are providing database service then I cannot see how this would be any different.
On a side note, there are quite a number of B2B scenario where the client provides the DB for data residency requirements and the service providers uses that DB to manage the data on behalf of the client.
The price is also a big concern, a user scope database is going to be quite costly, as a provider you would end up sharing the infrastructure
Lastly I will repeat it again, schema migrations are as much as database level concern, and migrating N databases above a certain scale is not easy.