5 ms·
No one here is answering your question so I will :) Database: I’d use whatever you know and helps you get to market, but abstract it away from the rest of your
by peterhunt 4y ago
No one here is answering your question so I will :)
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.
- dustedcodes 4y agoThanks, really good points and I agree with a lot of it.
- rustyf 4y agoI've never actually seen anyone in 40 years actually swap out that database.
- pclmulqdq 4y agoI've seen it with postgres-compatible DBs and Cassandra-compatible DBs. Lots of databases build their frontends this way so that people can switch from postgres/cassandra to their product when they need a bigger DB or better performance. I've never seen anyone swap any other kind of database.
- delecti 4y agoI did once in my last job, because we were told AWS was sunning down SimpleDB. We were able to swap to DynamoDB with relatively little fuss (though obviously not none, no migration is entirely painless) because we abstracted it so well. Turns out that several years later, SimpleDB is still up and running, but it was probably a good migration anyway. 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.
- deleted 4y ago[deleted]
- simonw 4y agoI've been on a team that ported a production system from MySQL to PostgreSQL, because we wanted the ability to add columns without downtime (this was a few years ago before MySQL gained the ability) and we wanted to build features using trigram indexes.
- jmull 4y agoHeh, of course you get a bunch of responses about database swaps... 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).
- jimbokun 4y agoMy company did, when the DB vendor quoted as an astronomical price per server when the original licensing agreement expired.
- throwayyy479087 4y agoAWS swapped famously swapped out Oracle DB2
- rozhok 4y agoI did it once in my career. We've had one legacy PHP project designed to work for MySQL. I was in charge of bringing it back to live and I decided to host in on Heroku for the sake of simple deployment. While Heroku does have MySQL addons I opted for using Postgres. 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.
- peterhunt 4y agoI think it's fairly common to swap out your core datastore when you take your prototype / MVP and bring it to production, or the first time your product experiences hypergrowth. At point the codebase, schema and team are still small enough that this is feasible. In fact I suspect every Firestore app that hits any degree of scale swaps out the DB for at least a subset of the app. So I agree with you with this one important exception.
- UnpossibleJim 4y agoWhat even does the idea of a decentralized social network look like? 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.
- matai_kolila 4y agoI'd go for redis a bit earlier, it's just so easy to use! I wouldn't cache much at all to start, then at like 10k users (or wherever my benchmarking says to) I'd include it w/redis. 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.