|
|
|
|
|
|
by ebiester
1 day ago
|
|
|
1. How do you get around performance issues? If I have a difficult join and you have a slow database, or you have a flaky connection, how can I debug the problem on my end? 2. What stops me (or any attacker) from exploiting your lack of security? Are you 100% sure you are secure? 3. You mention collaboration - How does this work at a company level if we have many users and need to control access - the company is the entity with rights to the data in this case. |
|
|
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