> 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.
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.