LiteDB: A .NET embedded NoSQL database

LiteDB is a database engine, so it needs persistence.

For the link you provided, I wonder if Microsoft would accept a pull request to merge it into the standard library to replace the built-in concurrent dictionary…?

I agree. The way I see it, a document DB (I have used Firebase) has features that make it nicer to work with documents. For example Firebase let's you query and index based on the data within the "JSON" (in quotes because it is not really represented in Firebase as JSON, but is close in structure).

Another thing is you might want the lack of features. I.e. you want it so people don't do joins etc. Because you want the team to use the same paradigm with local data as with server hosted. I can think of reasons why.

> I think you chose this instead of MongoDB like you would chose SQLite instead of MSSQL. The library is very similar to Mongo's .Net library, so its almost a 1:1 code replacement.

I guess it depends on what's important.

Some people primarily care about the API. Other people focus on the operational story.

In my experience the overhead is only noticeable if you use Entity Framework Core to interface with Sqlite.

The native Sqlite wrapper libraries such as Microsoft's Microsoft.Data.Sqlite have faster performance than EF, but because you're forced to pass around SQL strings, most .NET dev's don't prefer to use them.

I wonder if anyone's working on compiling SQLite's C code into C# so it can run without interop.

Isn't this why a qa environment is for?

That definitely has shifted in meaning over the years then. I remember when the selling point of these DBs was the exclusion of SQL.

Do you have more information about your game and how you are using LiteDB?

EF Core briefly had a (beta-level) MongoDB-compatible provider. It wasn't very useful in practice, but EF Core blogs every now and then talk about returning to document database support as a possibility.

I don't think I would use EF Core with a document database, but I can understand the appeal in sharing models with EF Core, and maybe even utilizing a shared "Change Tracker". Unless you are doing your own things, most EF Core models should be POCOs easily enough serializable to JSON to directly use in your document DB, and EF Core contexts at this point have an easy enough Change Tracker API to query that you could possibly reuse it easily enough for a document DB (though that is probably overkill because you don't need per-property tracking at that point usually, just per-document tracking).

Everybody can write a linq provider, it's just not that easy.

Ravendb has a great linq provider and is a nosql db.

> Is this about multiple processes using the same database

For me, yes. I experience a pretty large performance hit on shared vs direct mode. That being said, shared mode does seem to work with multiple processes; However, all processes must be on the same machine, as he uses a mutex around critical code. Or at least, he did last time I looked at the codebase.

If your DB is on a network location and the processes are on different machines, bad things will happen.

My experience is that LiteDB in direct mode is faster than SQLite, but in shared mode is slower.

Yes. Basically some processes failed to open the shared database.

Serilog wasn't the issue, I'm still using it. The problem was LiteDB not being able to open a database sometimes, and also reading those logs through LiteDB Studio was a PITA.