Probability is not binary. The probability that you will want to move your app, cross-cloud distribute your app, or get it turned off is much higher than those things you mentioned. This is also true about the contents of the data instead of just the ifaces since using NoSQL databases often means distributed in lieu of backups.
It's not that hard to run a few Cassandra machines, or if you can accept relational, RDS or other managed Postgres options are fine. It's just this vendor lock in stuff gets really annoying to refactor/migrate IME and in many cases if your time to market is that important, use a cloud-provided RDBMS that will let you be portable. I'd rather go from PG to Cassandra than Google data store to AWS data store to whatever other provider data store du jour.
While you're busy building your platform-agnostic wondertrap with Cassandra nodes and Docker images and Chef scripts and monitoring and all the other bells and whistles, I'm sitting down at my keyboard and implementing customer-facing features.
The probability that you will want to cross-cloud distribute your app is infinitesimally small compared to the probability that you will never get the right set of features to make your product take off. Platform portability is fake work that makes developers feel productive about doing something that their customers couldn't give a rat's ass about.
There's a reason Pivotal doesn't let you point chores - your velocity is determined only by how fast you make the customer happy. Focus on developing features, and use whatever tools get you to product-market fit fastest.
> While you're busy building your platform-agnostic wondertrap with Cassandra nodes and Docker images and Chef scripts and monitoring and all the other bells and whistles, I'm sitting down at my keyboard and implementing customer-facing features.
I'm not sure if you're responding to a different comment or missed where I suggested just use the cloud Postgres. I specifically mentioned time to market and acknowledge it. I am saying you don't have to sacrifice portability for time to market, and what is terrible advice is suggesting that you do.
I love Postgres, I really do. And Google's Cloud Postgres is my "default" axe.
It will not easily give you scale. It will not give you the ability to "not think about your database". You will not be able to go fishing (or wherever) with confidence that your app will just keep running without you.
I find there are two sweet spots for GCD (and probably DynamoDB, although I haven't used it in anger):
1) Persistence for really small and/or simple systems. Services that need a tiny bit of persistent state and really could do without the fuss of setting up databases and running migrations.
2) Persistence for big systems that need absolute rock solid availability, and can relax (or shunt off) analytical needs. Postgres is always one poorly-thought-out migration script away from downtime, and how many organizations test their migration scripts against full copies of the production database? Even Stripe has database-driven downtime, with their armies of developers and devops. Your two-person startup hasn't got a chance.
For everything else (and I'll be the first person to say that includes the majority of web applications!) there's Postgres.
It's not that hard to run a few Cassandra machines, or if you can accept relational, RDS or other managed Postgres options are fine. It's just this vendor lock in stuff gets really annoying to refactor/migrate IME and in many cases if your time to market is that important, use a cloud-provided RDBMS that will let you be portable. I'd rather go from PG to Cassandra than Google data store to AWS data store to whatever other provider data store du jour.