You wouldn’t store this information on the same table (unless you’re using a wide row db like dynamo/Cassandra). In a SQL world, you’d store version information in a separate table - one table for the HEAD state and another for history.
You wouldn’t store this information on the same table (unless you’re using a wide row db like dynamo/Cassandra). In a SQL world, you’d store version information in a separate table - one table for the HEAD state and another for history.
Disclaimer: I work in the central Delivery Engineering org for a FAANG. Our system deploys somewhere in the range of 30-50,000 times per day through our system and the number of services that require downtime for an update I could count on one hand.
Downtime is completely unnecessary in modern service development. If I experience a product that uses downtime for deployments, I take it as an indicator that the product is immature and probably not built in a way that I want to depend on for personal or professional life.
I totally get for small businesses maybe downtime is a necessity because it does require additional effort, but if you’re building a product or service that people depend on, it severely erodes trust and frustrates users.
Always release backwards-compatible changes. If you need to do a schema migration, ensure the DDL can be performed online and if it can’t, dual write.