As a young fledgling startup, you should not be building layers of abstraction over the technology that you are using; on the contrary, you should be going all in.
I have talked to multiple startups doing this. The intention is to future proof the product; this should be the least of your concerns during the early days. In your gestation period, you should be spending your waking hours building features to acquire customers and grow. That is what will make or break your startup, not the abstraction layers you create for the distant future.
If you are using MySQL, then go all in on it. MySQL has a lot of features that are above and beyond the ANSI SQL standards. Do not try to be standard compliant and avoid the esoteric non-standard features; try to leverage them as much as possible. It will take you faster to market at the cost of being locked in on MySQL for the foreseeable future. If your startup survives to see the day when MySQL becomes the bottleneck, you will have enough resources and expertise to make the switch. Same applies to cloud providers. Do not try to be cloud agnostic; utilize the features given by your cloud provider to the maximum.
This might sound orthogonal to some of the advice that you might get on the internet as well as sound engineering practices. A lot of these are written for mature companies with established product and revenues, not for young, early-stage startups. As with everything, it is all about context.
If you think about this, it boils down to a simple decision; whether you live in the present and try to maximize for today and the immediate future or plan out for the distant, uncertain future. A young startup, trying to make its mark on the world, should do the former.
This is a bit counter-intuitive and becomes challenging to do if you have a mindset that is more attuned towards a systematic way of thinking and doing. A lot of things with startups are counter-intuitive and go against the grain. If not, would it not be a cake walk?
Abhirama's Blog 