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, but the limits vary wildly. Some cap at storage (Supabase: 500MB), others at compute (PlanetScale: 1B row reads/month), and some at connections (Neon: 0.25 CU). The key question is: will the free tier support your use case through the first 6-12 months? If you'll hit limits in month 2, 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.