# Phase 1 gate — mongo-lite vs MongoDB 8.3.7, 1g dataset / ~16k docs
# ratio < 1.0 = mongo-lite faster. Reproduce: bash tests/e2e/compare-run.sh 1g 16k
# commit: 9eecb50

benchmark                                   mongo-lite              mongodb                 ratio
insertOne (sequential) x200                 0.19 ms                 5.1 ms                  0.0x
bulk insert throughput                      755.6 MB/s              688.7 MB/s              1.1x
docs loaded                                 65,536                  65,536                  1.0x
createIndex({k: 1})                         60.2 ms                 80.6 ms                 0.7x
countDocuments({})                          2.1 ms                  13.8 ms                 0.2x
findOne({_id: <ObjectId>})                  0.53 ms                 0.84 ms                 0.6x
findOne({k: 500}) (indexed)                 0.55 ms                 1.7 ms                  0.3x
find({p: {$gte,$lt}}).count() (scan)        20.5 ms                 13.1 ms                 1.6x
find({}).sort({_id:-1}).limit(20)           6.7 ms                  2.5 ms                  2.7x
find({}, {proj}).limit(1000)                3.5 ms                  4.4 ms                  0.8x
aggregate $group by k                       10.3 ms                 12.9 ms                 0.8x
updateOne({_id}) x50                        0.14 ms                 0.19 ms                 0.7x
updateMany({k: 7}, {$inc})                  16.2 ms                 6.5 ms                  2.5x
deleteOne({_id}) + insertOne                0.61 ms                 5.0 ms                  0.1x
node client RSS                             152 MB                  156 MB                  1.0x
server RSS                                  1975 MB                 1379 MB
kill -9 reopen                              0.8s                    1.3s
db on disk                                  1025MB                  92MB

# Baseline before Phase 1, for reference:
#   bulk insert 267 MB/s | createIndex 0.66s | sort+limit 40ms
#   range-scan 25ms | updateMany 20ms | reopen 3.8s | disk 1.0GB | RSS 2.0GB
#
# Remaining gaps and where they are addressed:
#   db on disk   11x  -> Phase 3 (block-compressed log)
#   sort+limit  2.7x  -> Phase 2 (index-ordered scan, _id as an ordered index)
#   updateMany  2.5x  -> Phase 2 (B+tree: remove_id is a linear scan per index)
#   range-scan  1.6x  -> 1.9 (per-field-per-doc allocation in the matcher)
#   server RSS  1.4x  -> Phase 4 (per-document arena -> byte storage)