Object oriented applications usually needs object oriented storage. Relations are good at mapping pointers but many technical limitations are hidden under documentation crust. It is not easy to choose the right database technology because pros are written everywhere and cons are spread across many GitHub issues. It is like buying a new car. You know the price, power and fuel consumption but you must inquire into reliability and maintenance costs.
SQLite
- Impossible to rename or remove existing table column.
SQLite is written in C which limits UWP processor architectures to those that SQLite supports because Windows does not have SQLite build in. It is not big deal but LiteDB does not have this limitation. SQLite requires SQLite for Universal Windows Platform Visual Studio extension which updates automatically but you need to manually recreate project reference to SDK every time it happens. Database version can be tracked by user_version pragma statement which is both simple and effective. When you want use Entity Framework Core you must target at least Windows 10 Fall Creators Update in which UWP supports .NET Standard 2.0.
Realm
- Doesn’t support Unicode characters in file paths.
- Doesn’t support foreign key in query.
- Object properties are accessible only inside using block of the database context.
- The query doesn’t support multiple values in where clause.
- It is impossible to use await inside using block of the database context.
- Once set, the primary key cannot be modified.
- The query doesn’t support projection.
Realm lacks UTF-8 characters support for file paths. It means that Realm is not able to open a database file when user profile name contains characters outside ASCII table. This bug was persists more than one year after beginning support of UWP and no fix is planned. Realm is usable only for Android or iOS environments. It also relies on Fody which injects some code changes inside build process. When Fody updates build breaks.
LiteDB
- When the query has more and operations engine will run only one condition with index and other conditions will use full scan.
LiteDB is written in C# which means it nicely fits Visual Studio, NuGet and .NET environment. It requires .NET Standard 1.3 which is implemented since UWP 10.0.10240. It is very useful for simple applications but when data manipulation requires complex rules and performance has a high priority it turns out that LiteDB needs some speed optimizations.