Probably a bigger benefit though, is being able to use a different DB in production (probably big scale) vs on your personal machine while developing.
But I think the point is still valid. You probably don't want your early design to focus on an edge case.
That said, a clear API between your DB and app is worthwhile for a lot of reasons (in general).
So we've just switched underlying connection and fixed a dozen of (mostly reports) places with plain SQL queries with MySQL-specific syntax. ORM library handled rest just perfectly.
So I agree with you with this one important exception.
Every social web I imagine branches out from me (if I am the user in question) and then goes out to gather information from there. So on and so forth. Unless I'm thinking about the wrong information gathering system.
React is a decent choice also here because you can port it wherever. One code base for web/iOS/Android is probably critical given how few dev resources you'd want to spend on it (you've got the right idea there too).
Also agree w/r/t decentralization. I think this is a fantasy for nerds but most people really do not care about privacy no matter how much people try to explain it to them.
I guess one thing I would add here is I'd work very hard to minimize operational costs for as long as I can, until you can show the explosive growth that'll interest investors. There are a ton of scrappy ways to save money on a tech stack like this early on, and you can probably find a way to get that AWS/GCP/Azure credit money to basically make this free to operate until your F&F round.
One you have a userbase, just... idk, iterate with them. Everyone and their mother probably has ideas for what they'd like Not-Twitter to be, but finding what the GCD is for that would be important to sustain growth I bet.
Database: I’d use whatever you know and helps you get to market, but abstract it away from the rest of your app so you can swap out later. Lots of good choices here; I’d pick mysql or postgres running on rds. I would also design for sharding by user on day 1 because that can be extremely painful to add later, however, care would have to be taken to ensure it doesn’t slow you down too much early. I’d also just use an rdbms for caching unless it becomes a problem, only then would I reach for redis. I would also avoid a fanout-on-write approach in favor of fanout-on-read. It will save you a lot of headaches later.
Firestore is nice but can get expensive quickly so I’d plan for it to be a temporary thing.
2. Would go for a react native app first but there are lots of options to choose from. Go with tech you know but keep in mind that it’s basically impossible to get a AAA mobile experience on web, and in this space polish really matters.
3. Decentralized social networks never took off because they are too hard to build. Avoid at all costs unless you have some angle (ie you have some novel tech discovered during your PhD). A middle ground could be a centralized network that is open source and makes data portability front and center.
I’ll also say that growth matters a lot here. As a founder I think 20% of the teams headspace should be thinking about engineering. The rest on growth and retention.