Slightly off-topic, because we use PostgreSQL on the backend, but because StoryArk is offline-first, we heavily rely on SQLite in our mobile app. The backend database is mostly just there to backup your local data and to sync it across all of your devices. So there aren't that many queries being run on the backend database.
I can't really count how many times I've been pleasantly surprised by how extensive the feature set of SQLite is. I mean, it even has window functions (https://www.sqlite.org/windowfunctions.html).
And being able to quickly open up the app's SQLite file in a database browser is also quite helpful during development.
Hi, one of the founders of StoryArk (https://storyark.eu) here. Our product can be used as a Google Photos alternative, but our goal is more to be a journal of your life, which you can share with your friends and family.
It's not self-hosted, but it might be of interest to you nevertheless.
I really like your idea. We're building something similar with a focus on photo sharing.
Have you considered making the contact book upload an opt-in? We also thought about connecting our users via their phone book, but we chose a different approach as we're concerned about privacy.
If you make the contact book upload opt-in, you at least give the user the chance to try out
the app before giving away the contact details of their whole phone book (without their permission).
I can't really count how many times I've been pleasantly surprised by how extensive the feature set of SQLite is. I mean, it even has window functions (https://www.sqlite.org/windowfunctions.html). And being able to quickly open up the app's SQLite file in a database browser is also quite helpful during development.