+Dmitry as well, in case they've looked at this.

So we have this thing, slow reports (go/slow-memory-reports), which gets data from dev/canary population. According to the data, in 40% cases leveldb consumes less than 0.5 MiB. In 18% cases it consumes 2-4 MiB. 4-8 MiB bucket accounts for 6%.

Hmm, thanks Dmitry! That's very interesting. Ideally we would be able to see (total memory / number of entities) for each DB as number of entities changes... is that something it would be possible to do? I don't know how those numbers are collected.

I think it should be possible, but we'll have to implement something similar to "leveldb.approximate-memory-usage" property LevelDB::OnMemoryDump() reports now, but for the number of entries.

If we are worried about the overhead, leveldb::Cache::Prune should clear the caches used in database. There was a plan to prune database cache on low memory pressure, but I didn't find any improvement in memory, so didn't implement it. Also, I have not investigated if it does clear all overhead.
+tzik who added this method.

The data shown in comment #2 includes the levelDB usage from LevelDBValueStore, IndexedDB and ProtoDatabase. It is not an universal total. To include usage from sync's levelDB database, we need to implement a dump provider (dskiba is working on it). For tracking total memory / number of entities from users, we could just add an attribute in the OnMemoryDump method if we know the number of entries.

BTW, in  issue 711518  we're discussing leveldb::Options and their impact on memory.