IMO you're worrying about the wrong thing right now. Build your API and application without any backend persistence. Make sure your API works. This will result in a nice data API for your backend that you can then plug into various tools.
Use this to test and play with and empirically figure out what the best persistence layer is for your app. There's no possible way you know at the beginning of the app what persistence is best for your app, so don't make that decision yet.
I agree with your approach. I feel though that the angle to take would be something like mongo... where I do not need to worry about a schema/migrations etc... and rather focus on the API logic itself.
I'm a big fan of relational databases. The problem with them is the high upfront cost of developing a new product: maintaining your schemas, updating data types, getting bogged down in data mapping code and worrying about what the most efficient SQL implementation is going to be, etc.
I like the fact I can whip something up quickly with MongoDB, get everything working and then once my schemas and services operating thereupon have stabilised then I can start looking at swapping my implementations out for a SQL-based back-end if I think it's worthwhile.
Use this to test and play with and empirically figure out what the best persistence layer is for your app. There's no possible way you know at the beginning of the app what persistence is best for your app, so don't make that decision yet.