monSQLize
  • English

      • Performance evidence and claim policy

      Performance depends on workload shape, MongoDB topology, indexes, network latency, cache backend, document size, concurrency, and hardware. monSQLize therefore does not promise fixed speedup multipliers or universal overhead percentages.

      Evidence contract

      Any numeric performance claim must record all of the following before it is presented as a project result:

      FieldRequired evidence
      WorkloadOperation, options, warm/cold state, concurrency, and comparison baseline
      EnvironmentNode, MongoDB/driver, CPU, memory, operating system, and network topology
      DatasetDocument count, shape, indexes, and cache population state
      CommandA repository command or script that another maintainer can run
      ArtifactRaw samples plus summary statistics, with commit and timestamp
      BudgetA regression threshold tied to that workload, not a product-wide guarantee

      Current verified scope

      • npm run test:performance is a controlled FunctionCache regression guard. It validates hot-path/coalescing behavior under its fixture; it does not prove a fixed production speedup.
      • npm --prefix website run check:budgets guards built asset and search-index size trends. It is a transfer-size budget, not a page-load latency claim.
      • Batch writes, query caching, populate, findPage, DataTask, SSH, and slow-query logging are documented qualitatively until each has a reproducible workload and stored artifact.

      Benchmark your own workload before selecting batch size, cache policy, pool size, or operational timeout.