If you're concerned that a service might shut down then you need to architect your application with that in mind, in which case how much of a rewrite is necessary is essentially up to you. Usually there's a tradeoff between going fast and engineering solutions that will work in the long term. Most startups never get to the stage where they need to swap out a service, so closely tying your application to a service is probably OK at the start.
If the service that shuts down is reasonably popular though it's likely there'll be very little code to change. API-compatible competitors will pop up to replace it. It happened when Parse closed.
The thing is, oftentimes these closed source database solutions aren't appreciably faster than choosing a managed solution that uses existing technology, like a hosted Postgres / MongoDB / whatever provider. In those cases your switching cost is vastly reduced, it's essentially a purely operational concern and your code doesn't need to change at all.
If you're concerned that a service might shut down then you need to architect your application with that in mind, in which case how much of a rewrite is necessary is essentially up to you. Usually there's a tradeoff between going fast and engineering solutions that will work in the long term. Most startups never get to the stage where they need to swap out a service, so closely tying your application to a service is probably OK at the start.
If the service that shuts down is reasonably popular though it's likely there'll be very little code to change. API-compatible competitors will pop up to replace it. It happened when Parse closed.