Unity and data storage

Tulenber 28 February, 2020 ⸱ Beginner ⸱ 4 min ⸱

- Do you have any expertise in SQL?
- No
- …

Creating a post about setting up SQLite in Unity is a worthy goal for any self-respecting blogger. Still, for some reason, this post is about data storage methods that are popular in the community and offered by third-party products and assumed that technology descriptions make you think about the architecture of the project. Also, instructions for setting up any circuit described further easily found on the Internet.


Why any game must have data storage must be oblivious, so let’s describe this very fast.


A game is an action to change the source data for some purpose.

Source data

The community postulates quite often - the way to create source data in Unity is to prepare sets of Prefabs, ScriptableObjects, Scenes, and tools for managing them in the editor. Other config types are not needed.

Data to store

Changes in Prefabs, ScriptedObjects, and Scenes cannot be saved, so after reloading of the scene, everything will return to its original state, respectively, any states that need saving require some data storage. Example: if you can put blender from the table into inventory, you must save the absence of it on the table and its presence in the inventory.

Existed solution

The only ready-to-use way to store data in Unity is PlayerPrefs; this is a prevalent solution in the community’s answers about storing something.


  • Very easy to implement


  • Stored in open format
  • Not so fast
  • They are stored in strange places; for example, on Windows, they are stored in the registry with a limit of 1 MB per record. Also, it has different restrictions on different platforms.

As a result, the name speaks for itself; it is a tool for storing settings and other not very large and unimportant information.


All other methods will require serialization, lets overview most popular of them:

  • Binary - challenging to edit and share, but generally good.
  • CVS - for some reason, this is the first answer about databases and Unity on Reddit... Are you serious?
  • XML/JSON - good old formats, only the number of symbols is different.
  • ProtoBuf like - for example MessagePack or FlatBuffers. What is it, how to use it, and why Json is not so good can be found right on the FlatBuffers page.


The obvious way, it’s easy to implement, problems start with a large number of files, both manageability and performance are falling.


The only candidate will be:

  • SQLite - fast, simple, time-tested, generally winning standard.

There are other options in the Asset Store, which include the acronym SQL in the name, but they look very much like wrappers over the same SQLite. There are ORM solutions to make life easier, for example, sqlite-net. So if there is a need for a relational database, then it makes no sense to look for something else.


A popular topic of the last decade, and thanks to that, there is more than one option:

  • SQLite - who can forbid us to use it as kv-storage?
  • iBoxDb - exists for a long time, claims support of Unity out of the box, someone say that use it.
  • LiteDb - unlike the previous candidate, there are more articles about using it, there are even tables comparing performance with files and SQLite in which it looks excellent. Also you can look at our new article LiteDB and Unity.

At the moment, the choice of NoSql solutions has become the standard, and one can hardly come up with an excuse not to use them. It is clear that SQLite looks the most popular solution here, and the rest do not have a hundredth of its popularity.

High scalability, high availability enterprise production platform

Recently there are many mentions of Realm.io and similar solutions that allow you to configure the synchronization of local and external databases, removing most of the work from developers. Unfortunately, Realm.io, although it claims to support .Net Standard 2.0, doesn’t want to start under the Unity of the latest versions, so it remains to expect when their new owner, MongoDb, will turn his attention to the gaming industry.

Alternatives worth paying attention to:

  • Firebase - declare support for Unity. In recent versions, the offline mode has added lately.
  • CouchBase - declare support for Unity in the mobile version.

Of course, these are solutions for enterprise-level tasks and for those who make the next Hearthstone and understand why it is needed.


On the one hand, this article was not supposed to give a silver bullet to kill all the projects. On the other hand, the choice of options offered by the community is not so wide, and everything resolved in the old fashion way with binary/json + file/sqlite solutions. It seems like a community is so easy on this topic due to other performance issues. But, if you want to have some adventure, there are LiteDb and FlatBuffers awaits. I will try them, but this will be a completely different post. See you next time! =)

Update: also you can look at our new article LiteDB and Unity

Privacy policyCookie policyTerms of service
Tulenber 2020