[zero1zero]

I would like to know more about this as well.

It sounds like they are all SQL Server instances. However, he made it seem like they are reproducing the schema once per site? I.e., a separate database per site rather than sharding the shared data to multiple hosts per site. Did I hear this right in the question/answer portion?

[kmontrose]

Stack Exchange has one database per-site, so Stack Overflow gets on, Super User gets one, Server Fault gets one, and so on. The schema for these is the same.

There are a few wrinkles. There is one "network wide" database which has things like login credentials, and aggregated data (mostly exposed through stackexchange.com user profiles, or APIs). Careers Stack Overflow, stackexchange.com, and Area 51 all have their own unique database schema.

All databases are MS SQL Server.

[avemg]

How do you manage schema changes with release deployments across across all of the databases that are meant to be standard?

[sklivvz1971]

All the schema changes are applied to all site databases at the same time. They need to be backwards compatible so, for example, if you need to rename a column - a worst case scenario - it's a multiple steps process: add a new column, add code which works with both columns, back fill the new column, change code so it works with the new column only, remove the old column.

[avemg]

Thanks for the reply. We have a similar architecture where I work so this is interesting to me. A couple more questions if you don't mind:

- Do you use any tools for orchestrating the rollout of those schema changes or do you just have some homegrown scripts?

- Do you separate your schema versioning and deployment process from your application versioning and deployment process?

- How do you handle cases where backwards-compatibility is not possible? For example, a new application feature that depends on a brand new table.