Choosing a data store for a .NET cloud service rarely happens in isolation. Teams juggle legacy schemas, developer expertise, and shifting product requirements while keeping an eye on cloud costs. The author walks through real‑world decisions between SQL Server, PostgreSQL, MongoDB, and DynamoDB, sharing hard‑earned lessons.

Data shape drives the split: complex relationships and join‑heavy reports favor relational engines with ACID guarantees, while document‑like, rapidly evolving payloads thrive in NoSQL. A SaaS product migrated user‑profile storage to MongoDB after schema migrations stalled, yet later added a job‑metadata service in MongoDB that broke when ad‑hoc queries demanded SQL‑style indexes.

Scaling considerations round out the decision. Vertical scaling via Azure SQL or AWS RDS satisfies most workloads, but write‑intensive telemetry moved to DynamoDB for horizontal throughput, exposing join pain points. The author advises starting with relational storage, adding NoSQL only where flexibility or massive scale is proven, and budgeting for validation and migration overhead.