Core Data Store
Also known as: core data sqlite store, persistent store ios, ios core data store
A Core Data store is the on-disk persistent backing of an app's Core Data object graph, most commonly a SQLite database file. It holds the app's structured data and can grow large over time as records, indexes, and write-ahead logs accumulate.
- The default Core Data store is a SQLite database, often with -wal and -shm companion files.
- Deleting records may not shrink the file, SQLite reuses freed pages instead of releasing them.
- Large binary attributes can be stored externally in a .sqlite_SUPPORT folder beside the database.
What a Core Data store is
Core Data is Apple's object-graph and persistence framework. The objects you work with in memory are saved through a persistent store managed by an `NSPersistentStoreCoordinator`. The default and most common store type is SQLite, which writes a `.sqlite` database file (plus `-wal` and `-shm` companion files when write-ahead logging is enabled) into the app's container.
Other store types exist, including binary (`NSBinaryStoreType`) and in-memory (`NSInMemoryStoreType`), but SQLite is preferred because it supports incremental saves, faulting, and querying without loading the whole graph into RAM.
Why the store grows and bloats
A Core Data SQLite store grows as the app inserts rows for entities, builds indexes, and stores external binary data (large `Binary Data` attributes can be written as separate files in a `.sqlite_SUPPORT` folder). The `-wal` file can also balloon between checkpoints. Deleting managed objects does not always shrink the file, because SQLite reuses freed pages rather than returning them to the filesystem.
This is why an app that stores cached records, attachments, or history in Core Data can occupy far more space than its fresh install size, the bulk lives in the persistent store, not the app binary. Migrating or vacuuming the store reclaims space, but day to day this growth shows up as the app's documents and data footprint.