| Design your stack around where the organization is growing in a business perspective: early stage start-ups are very fast organizations. You have to design your stack in a way, early on, that supports failed assumptions, which means frequently changing requirements at the same leaving enough room to breathe and grow. Scaling equates to specialization, you specialize in a specific area of your stack because your startup has grown in that direction. In a very early stage, there's not much growth only a period of intense validation, so don't overthink about scale right now. If you are using PostgreSQL, just stick with it. You can ship things faster and troubleshoot better with stuff you know. In terms of fetching data, you can design it in a way that you actually don't have to do any joins at all. Twitter still uses MySQL up until this very day, they've customized the core engine for their purposes. Point is: don't over-think about storage for now, no one knows right now where your startup will grow into :) Build and design a pleasurably usable RESTful HTTP API Server with a matching client: in my experience this is very very helpful. At a very early stage, building an API server allows you to pivot relatively quickly. When you have a "proxy" for your database, it's practically developer-UX for fast changing business requirements, and it will avoid "database code hell" ie, random projects doing random things at your database. Imagine you're building this huge web-app, but the users clearly want and need a mobile equivalent. What if the users want some sort of on-site installation for an enterprise version? Suddenly you're not a B2C startup and you'll be going on B2B. An API server helps you do tons of things that enables you to ship applications faster and makes your startup very flexible since you can isolate and maintain this very large part of your product. |