I've been running the numbers on a few recent migrations, and a pattern is emerging. Everyone talks about Lambda or Cloud Run lock-in, but the real sticker shock and architectural glue is coming from the database layer. Once you go serverless DB, extracting your data *and* your application logic becomes a multi-year project.
My hot take: The "pay-per-query" or "per-request" operational model is the easy sell. The real lock-in is in the **proprietary data APIs and the tight integration with the provider's ecosystem**.
Think about it:
* **AWS DynamoDB:** Your access pattern is now `Query` and `Scan` operations. Moving to another key-value store means rewriting every data access layer.
* **Azure Cosmos DB:** You commit to a specific "API" (like MongoDB, SQL, Gremlin). But it's not the real OSS version—it's a surface-level compatibility that uses Cosmos's own core. Try moving that "MongoDB API" data to real MongoDB without a major migration project.
* **Google Firestore:** You design your data hierarchy for collections and documents. The offline sync and real-time listeners are fantastic, but they're entirely proprietary.
The cost scaling is where it gets sneaky. It feels free at low usage, but the meter runs on:
- Read/write units (which you have to provision or risk throttling)
- Indexed data storage (often more expensive than raw GB)
- Backups (sometimes a separate, premium service)
- Data egress (if you ever want to leave)
I just modeled a mid-sized app moving from DynamoDB to a self-managed Cassandra cluster on VMs. The serverless DB was 40% cheaper for the first 8 months. After that, the flat VM cost crossed over and saved ~30% annually. But the migration cost? Equivalent to 18 months of the higher bill. You're trapped in the "it's cheaper to stay" zone.
Has anyone done a serious cost/benefit on this? When does the operational overhead of managing your own DB instance outweigh the flexibility penalty? I'm starting to think the break-even point is much further out than the marketing suggests.