This needs more attention than it's getting. Perhaps if you made some changes to the landing pages could help?

"outperforms the fastest JSON libraries (that make use of SIMD) by up to 120x depending on the benchmark. It also outperforms schema-only formats, such as Google Flatbuffers (242x). Lite³ is possibly the fastest schemaless data format in the world."

^ This should be a bar graph at the top of the page that shows both serializing sizes and speeds.

It would also be nice to see a json representation on the left and a color coded string of bytes on the right that shows how the data is packed.

Then the explanation follows.

FTA#1: “Hashmaps do not (efficiently) support range queries. Since the keys are stored in pseudorandom order”

FTA#2: “Object keys (think JSON) are hashed to a 4-byte digest and stored inside B-tree nodes”

It still will likely be faster because of better cache locality, but doesn’t that means this also does not (efficiently) support range queries?

That page also says

“tree traversal inside the critical path can be satisfied entirely using fixed 4-byte word comparisons, never actually requiring string comparisons except for detection of hash collisions. This design choice alone contributes to much of the runtime performance of Lite³.”

How can that be true, given that this beats libraries that use hash maps, that also rarely require string comparisons, by a large margin?

Finally, https://lite3.io/design_and_limitations.html#autotoc_md37 says:

“Inserting a colliding key will not corrupt your data or have side effects. It will simply fail to insert.”

I also notice this uses the DJB2 hash function, which has hash collisions between short strings (http://dmytry.blogspot.com/2009/11/horrible-hashes.html), and those are more likely to be present in json documents. You get about 8 + 3 × 5 = 23 bits of hash for four-character strings, for example, increasing the risk of collisions to, ballpark, about one in three thousand.

=> I think that needs fixing before this can be widely used.

“By default, deleted values are overwritten with NULL bytes (0x00). This is a safety feature since not doing so would leave 'deleted' entries intact inside the datastructure until they are overwritten by other values. If the user wishes to maximize performance at the cost of leaking deleted data, LITE3_ZERO_MEM_DELETED should be disabled.”

You have to encode the type of all the binary data. Does that make it serialization?