When should I use a flat file for storage?

When the data is small, simple, or naturally a single document, since flat files are easy to implement and inspect but require loading the whole file and cannot be queried efficiently.

What is the difference between SQLite and Core Data?

SQLite is a relational database in a file. Core Data is an object-graph and persistence framework, usually backed by SQLite, that adds change tracking and platform integration along with a learning curve.

Is Core Data always the best choice on Apple platforms?

No. It fits apps with rich, interconnected object models. For simpler structured data, SQLite is often simpler, and for small document-like data a flat file may be best.

← All articles

March 17, 20267 min readstorage, core-data, sqlite, ios

Core Data, SQLite, or Flat Files: Choosing Local Storage

By Mykhailo Boichuk · Co-founder & Vice-President

In short

The right local storage depends on the data’s shape and how you query it. Flat files suit small, simple, or document-like data. SQLite suits structured data that needs querying, filtering, and relationships. Core Data is an object-graph and persistence framework on top of SQLite that fits apps with complex object models and tight platform integration, at the cost of its own learning curve.

Storage is a question about data shape

Choosing how an app stores data locally is often treated as a default, the framework everyone reaches for, when it should be a decision driven by the data itself. The relevant questions are how much data there is, how structured it is, what relationships it has, and how the app needs to read it. The answers point clearly toward one of a few options, and choosing against the grain of the data creates friction that lasts the life of the app.

There is no single best choice. Each option occupies a sensible range, and the skill is matching the option to the data rather than applying one tool to every problem.

Flat files for simple and document-like data

When the data is small, simple, or naturally a single document, a flat file is often the right answer. Storing structured data as a file, in a format such as JSON or a property list, is easy to implement, easy to inspect, and easy to back up or move. Its limits appear when the data grows large or needs to be queried, because reading a file means loading and parsing the whole thing.

Good for small data, settings, or document-style content saved and loaded as a unit.
Easy to implement, inspect, and make portable.
Poor for large datasets or anything requiring querying and partial reads.

SQLite for structured, queryable data

When the app has structured data with relationships, needs to filter and sort it, or holds more than fits comfortably in memory, a database is the right tool, and SQLite is the standard embedded choice. It is a full relational database in a single file, fast, reliable, and queryable, letting the app read exactly the subset of data it needs rather than loading everything.

SQLite is the workhorse of local storage on Apple platforms. It handles structured data and querying well, scales to large datasets, and underlies higher-level frameworks, so understanding it is valuable even when using something built on top of it.

Core Data for rich object graphs

Core Data is not a database but a framework for managing an object graph with persistence, typically backed by SQLite. It fits apps with a complex model of interconnected objects, offering features such as change tracking, relationship management, and integration with the platform’s data and UI mechanisms. The trade-off is a meaningful learning curve and a layer of abstraction that can be hard to reason about when something goes wrong.

The honest summary is a spectrum. Reach for flat files when the data is small and document-like, SQLite when it is structured and needs querying, and Core Data when the object model is rich and the platform integration earns its complexity. Matching the tool to the shape of the data, rather than defaulting to the most powerful option, produces an app that is simpler to build and easier to maintain.

Key takeaways

Choose local storage based on the data’s size, structure, relationships, and query needs.
Flat files suit small, simple, or document-like data and are easy to inspect and move.
SQLite suits structured data that needs querying, filtering, and scaling beyond memory.
Core Data manages a rich object graph on top of SQLite, with deeper platform integration.
Match the tool to the data rather than defaulting to the most powerful option.

Frequently asked questions

When should I use a flat file for storage?: When the data is small, simple, or naturally a single document, since flat files are easy to implement and inspect but require loading the whole file and cannot be queried efficiently.
What is the difference between SQLite and Core Data?: SQLite is a relational database in a file. Core Data is an object-graph and persistence framework, usually backed by SQLite, that adds change tracking and platform integration along with a learning curve.
Is Core Data always the best choice on Apple platforms?: No. It fits apps with rich, interconnected object models. For simpler structured data, SQLite is often simpler, and for small document-like data a flat file may be best.

References

Apple Core Data Documentation

About the author

Mykhailo Boichuk

Co-founder & Vice-President

Mykhailo is an engineer who builds native applications and the systems behind them. He concentrates on macOS and iOS performance, local-first data architecture, and the synchronization problems that come with offline-capable software.