[graealex]

The reason for using an embedded database is ease-of-deployment. Sometimes deployment size is relevant as well. Those use cases are usually oppositional - software that relies on a simple deployment usually doesn't require dozens of concurrent writers, and/or hundreds of transactions per second. Software that does usually needs a more in-depth installation anyway, or at least it's worthwhile to go the extra mile to optimize performance. Also the size of the dataset will often be orders-of-magnitude apart.

The reason for using an SQL database is that your data is structured in a way where using SQL to query it makes sense. Comparing SQL to No-SQL is pointless, unless your use case can be easily adapted to either of them, without suffering too much.

There are plenty of No-SQL embedded databases. A number of SQL embedded databases as well.

If speed, ease-of-deployment/embedded and SQL were important, I would use Firebird as an embedded database, like SQLite gets loaded into process memory. Depending on the version and feature set you include, this is also only a few MB, and even more ANSI SQL compliant than SQLite.

If you want to do comparisons, compare against other document/No-SQL databases.

[hashmak_jsn]

thanks for suggestion,I will compare with other no sql database.