Authorize, don't authenticate

Author here.

Thank you for your questions. I'll take a stab at answering them: * The underlying databases that ayb fronts are SQLite and DuckDB. Both are relatively battle-hardened RDMBSs. That said, I don't think the approach I'm proposing has any bearing on the difficulty of a query: if a centralized DB would struggle with a query workload, the personal DB is likely to as well. One saving grace is that workloads are slightly more isolated in my approach: someone else's data that's poorly shaped for a query shouldn't affect your queries, which is not something most all-users-in-the-same-database approaches can claim. * I make no special security claims beyond what is listed in the documentation [1]. ayb specifically has been used in production by low single digit numbers of people, so you should absolutely wait to use it for any super-sensitive data, especially in a shared/multi-tenant context. That said, you should be no more confident in the random web app that stores your data for you than you are in ayb's security. * This blog post is focused on personal data: the to-do list, the streaks/goals you've set out for yourself, your database of newsletter subscribers. I think there's some interesting work to be done in the enterprise around access control. In ayb, there are coarse-grained sharing/permissions [2], but I don't think that's enough for most enterprise situations.

[1] https://github.com/marcua/ayb#isolation [2] https://github.com/marcua/ayb#permissions

I remember all the confusion when I was first learning secure connection stuff, like ssl

Because when I saw "auth" ... was it authentication or authorization?

For the sake of discussion lets leave the business aspect. What you are offering is a service for managed database, similar to lot of cloud providers. What you have on the top of it is a OAuth2 process to obtain relevant credentials.

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.

Absolutely. A service has no business to know who you are. They should only care if the user has authorization.

Authentication has historical reasons. Employee access, citizen services etc all are identity based. Identity was translated into authorisation for multiple services instead of each service requiring it's own authorisation.

Vorlons authenticate, Shadows authorize