Usually, developers use Core Data and SQLite to save your application’s permanent data for offline use, to cache temporary data, and to add undo functionality to your app on a single device. Therefore, developers are very often confused with them for their differences. In this post, we discuss the differences between the two from four aspects.
SQLite has a data constraints feature, but Core Data does not. The most important difference between Core Data and SQLite is that SQLite is a relational database while Core Data is not. And Core Data looks like a document database sometimes.
SQLite operates on data stored on the disk. In contrast, Core Data operates on data stored in memory, in another word, data needs to be loaded from disk to memory.
Developers can drop tables and edit data without loading them in memory. However, Core Data need to load the entire data if developers need to drop table or update. Factually, there is no table in Core Data, very often, developers are confused with Entity (a Core Data concept) and Table (a relationship database concept).
An entity is represented by an instance of the
NSEntityDescription class. To clarity, an entity describes a data structure with many attributes (or properties). It’s not a dataset, just data type. Usually, we query data by data type with Core Data. In concept, it is very different from a relationship database.
SQLite is slow as compared to Core Data. In Core Data, your app loads all data from disk to memory on startup. Moreover, no constraint logic saves much more time than SQLite.
What should you use? Core Data or SQLite? It depends on what you want indeed. For example, if you are managing a complex object graph with many entities, attributes, and relationships, then Core Data is definitely worth considering. Getting up to speed with Core Data is easier than you might think. But If you need a lightweight solution and don’t need Core Data’s feature set, then SQLite may fit your needs.