How to offer multiple versions of an API with different database schemas?

I have no idea how spotify does this internally.

Just at a guess though from the way he was talking about it, I'm not sure these microservices were storing any data at all. I got the feeling that they were essentially a presentation layer on top of something else (perhaps an internal service layer).

If a microservice can have multiple versions active, and it is also the owner of some data then one of two things are probably happening:

• Schema consistancy is applied at the service level, if a change is made to the schema it must be updated in all historic versions. In the case of multiple versions being deployed independantly this would nessecitate a deploy of all versions on a schema change (he didnt talk like this was the case, but this is how I've always done versioning)
• Each version owns an independant copy of the data. To do this you really need to have a pub/sub model in the system and perform all modifications as a result of some kind of message. (to me this seems pretty inefficient unless its very low churn, but perhaps at that scale it might make sense, there is also a problem with how to prime a new version with data)

I dont think running a schema and never changing it would really work long term. Things change and changes are nessacary. One of the biggest benifits of microservies/SOA (IMO) is that change is easier as the domains are small and containted. You can do things like completely change the storage mechanism (perhaps even to a new type of storage) reasonably safely and quickly as the volume of code is low.

More thoughts on microservice versioning in my article, Microservice versioning; How to make breaking changes without breaking stuff