NSPersistentCloudKitContainer

When you use SwiftData + CloudKit, under the hood, the SwiftData framework converts SwiftData models to Core Data managed objects, and use NSPersistentCloudKitContainer to synchronize the objects with CloudKit. NSPersistentCloudKitContainer mirrors each Core Data managed object to (at least) a CloudKit record (CKRecord), as described in Reading CloudKit Records for Core Data. To manage the internal state of the synchronization, it adds a few tables to the store, and the ANSCKRECORDMETADATA table is one of them, which is used to store the metadata of the CloudKit records. The metadata includes the system fields and encoded data of every CloudKit record, so yes, you can see that the size of table gets quite large. The ANSCKRECORDMETADATA table is an internal data structure that NSPersistentCloudKitContainer creates and consumes. You can review the documentation mentioned above to make sure that your models are translated to CloudKit schema correctly, but other than that, I don't see a

SwiftData default store is based on Core Data. As a historical implementation detail, at runtime, a Core Data to-many relationship, once persisted, is always a [], and never a nil. To adapt this behavior in an effective way, SwiftData always initializes a nil to-many relationship with an empty collection at runtime. So to your first question, the behavior that optional to-many relationships in SwiftData are never nil at runtime is as-designed. The requirement that relationships must be optional is a way to express that NSPersistentCloudKitContainer does not handle relationships atomically, and is enforced by a schema validator at compile time. The validation doesn't have any impact at runtime, and so SwiftData to-many relationships being [] at runtime doesn't break the CloudKit synchronization. To use SwiftData + CloudKit, you make sure your model schema is compatible with the rules so the schema validator doesn't complain, and that will be it. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I'd like to comment the second question a bit, as it hasn't been addressed yet: Sometimes when running on a new device it will create a second UserSettings while it is waiting for the original one to sync from CloudKit. When you use SwiftData + CloudKit, under the hood, the framework uses NSPersistentCloudKitContainer to synchronize data. In that environment, duplicate data is sometimes inevitable, which is discussed in great details in the following section: Remove duplicate data The solution is to de-duplicate the data. How to do so is discussed and demonstrated in the sample code. Back to what to what you intent to achieve, my suggestion will be: If you plan to use SwiftData + CloudKit extensively in your app, you might need to handle duplicate data anyway. In this case, persisting user settings to your SwiftData store (and Synchronizing them via NSPersistentCloudKitContainer) makes a lot of sense. If the target is as simple as saving some Cloud-based user settings, I'd probably consider