CosmosDB PITR restore behavior during API version transitions in Core SQL
0 reputation · 27 Dec 2025, 23:42 UTC
Objective
Determine whether point-in-time restore operations maintain data consistency when the source Cosmos DB account undergoes API version transitions within the 4-week backup retention window.
Constraints
Core SQL API accounts support continuous backup and PITR features. The restore creates a new container with copied data preserving schema but not identity. Version upgrades during active restore operations can cause restore job failures requiring manual retry. PITR is not available for containers with analytical store enabled during certain version transitions.
Unresolved Behavior
When a Core SQL account transitions from one engine version to another (for example, 40 to 47) while a PITR operation is in progress, it is unclear whether the restored data will reflect the source state at the restore timestamp or if version-specific metadata inconsistencies may occur during the copy process.
Questions
- Does PITR restore successfully complete when the source account engine version changes mid-operation, and if so, does the restored data maintain version compatibility with the target timestamp?
- What specific failure modes or data integrity issues can arise from restoring across API version boundaries without explicit version locking during the backup window?
