Start with your data shape, not the hype cycle
The most common mistake teams make is choosing a database based on what's trending rather than what their data actually looks like. If your data is tabular with clear relationships, a relational database (Postgres, MySQL) is almost always the right starting point. If you're storing nested, schema-flexible documents, a document store (MongoDB, Firestore) makes more sense. Vector databases (Pinecone, Weaviate) are specifically for similarity search and RAG pipelines — they don't replace your primary database.
The team-size filter most people skip
A solo developer has different needs from a 50-person engineering org. If you're building alone or on a small team, operational simplicity matters more than raw performance. Managed services like Supabase, PlanetScale, or Neon eliminate the DevOps burden. Enterprise teams can justify self-hosting for compliance or cost reasons, but should budget 20-30% of an engineer's time for database operations.
Free tiers are not all created equal
Every database provider advertises a free tier — except when they don't. Some cap at storage (Supabase: 500MB), others at connections (Neon: 0.25 CU), and some have eliminated the free tier entirely (PlanetScale removed theirs). The key question is: will the free tier — if there is one — support your use case through the first 6-12 months? If you'll hit limits in month 2, or there's no free tier at all, factor in the paid pricing from day one.
When to use multiple databases
Modern applications often need more than one database. A common pattern: Postgres for your core transactional data, Redis for caching and session storage, and a vector database for AI features. The mistake is adding databases prematurely. Start with one, and add specialized stores only when you have concrete evidence that your primary database can't handle a specific workload.
The migration tax nobody talks about
Switching databases mid-project is one of the most expensive engineering decisions. It typically takes 2-4 months of dedicated work for a mid-size application. This is why the initial choice matters so much — but it also means you shouldn't agonize indefinitely. Pick a reasonable default (Postgres for most web apps), build your application, and only consider switching when you have concrete scaling data that justifies the migration cost.