{"id":38535573,"url":"https://github.com/itsfarseen/boltdb-benchmarks","last_synced_at":"2026-01-17T07:01:06.276Z","repository":{"id":298584583,"uuid":"1000395550","full_name":"itsfarseen/boltdb-benchmarks","owner":"itsfarseen","description":"Evaluate different strategies for storing records in BoltDB","archived":false,"fork":false,"pushed_at":"2025-08-28T08:45:20.000Z","size":659,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2025-10-11T14:34:44.340Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/itsfarseen.png","metadata":{"files":{"readme":"Readme.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2025-06-11T18:00:52.000Z","updated_at":"2025-09-09T13:55:22.000Z","dependencies_parsed_at":"2025-06-11T21:58:01.261Z","dependency_job_id":"30747875-9d5f-414e-a119-b692e0b22972","html_url":"https://github.com/itsfarseen/boltdb-benchmarks","commit_stats":null,"previous_names":["itsfarseen/boltdb-benchmarks"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/itsfarseen/boltdb-benchmarks","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/itsfarseen%2Fboltdb-benchmarks","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/itsfarseen%2Fboltdb-benchmarks/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/itsfarseen%2Fboltdb-benchmarks/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/itsfarseen%2Fboltdb-benchmarks/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/itsfarseen","download_url":"https://codeload.github.com/itsfarseen/boltdb-benchmarks/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/itsfarseen%2Fboltdb-benchmarks/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28503021,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-17T06:57:29.758Z","status":"ssl_error","status_checked_at":"2026-01-17T06:56:03.931Z","response_time":85,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-17T07:00:57.280Z","updated_at":"2026-01-17T07:01:06.252Z","avatar_url":"https://github.com/itsfarseen.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# BoltDB Benchmarks\n\nThis study evaluates different strategies for storing records in BoltDB and examines their performance trade-offs.\n\n---\n\n## Experiment Setup\n\nBenchmarks were run at the following record counts:\n\n* 10, 100, 1,000\n* 10,000, 25,000, 50,000, 75,000\n* 100,000, 250,000, 500,000, 750,000\n* 1,000,000\n\nEach scenario was repeated **10 times**, and results were averaged.\nThe full suite of tests required several hours to complete.\n\n---\n\n## Example Data\n\n```go\nfunc generateUser(id int64) *UserInfo {\n\trand.Seed(id)\n\treturn \u0026UserInfo{\n\t\tID:          id,\n\t\tUsername:    fmt.Sprintf(\"user_%d\", id),\n\t\tEmail:       fmt.Sprintf(\"user%d@example.com\", id),\n\t\tFirstName:   fmt.Sprintf(\"First_%d\", id),\n\t\tLastName:    fmt.Sprintf(\"Last_%d\", id),\n\t\tAge:         int32(rand.Intn(60) + 18),\n\t\tHeight:      float32(150 + rand.Intn(50)),\n\t\tWeight:      float32(50 + rand.Intn(100)),\n\t\tBalance:     rand.Float64() * 10000,\n\t\tIsActive:    rand.Intn(2) == 1,\n\t\tCreatedAt:   time.Now().Unix() - int64(rand.Intn(365*24*3600)),\n\t\tUpdatedAt:   time.Now().Unix(),\n\t\tLoginCount:  int32(rand.Intn(1000)),\n\t\tScore:       rand.Float64() * 100,\n\t\tDescription: fmt.Sprintf(\n\t\t\t\"This is a description for user %d with some random text to make it longer and more realistic.\",\n\t\t\tid,\n\t\t),\n\t}\n}\n```\n\n---\n\n## Storage Strategies Tested\n\nSix encoding strategies were benchmarked:\n\n* **Binary**\n\n  * One KV pair per record.\n  * Key = ID, Value = binary-encoded concatenation of fields.\n  * Most storage-efficient representation.\n\n* **Binary+Names**\n\n  * One KV pair per record.\n  * Value = alternating field names and values (no delimiters).\n  * Mimics JSON/Gob layout but without structural markers.\n\n* **JSON**\n\n  * One KV pair per record.\n  * Value = JSON serialization of struct.\n\n* **Gob**\n\n  * One KV pair per record.\n  * Value = Gob serialization of struct.\n\n* **MultiKV**\n\n  * Multiple KV pairs per record:\n    `ID1.Field1 → Value`\n    `ID1.Field2 → Value`\n    …\n\n* **NestedBuckets**\n\n  * One bucket per record, keyed by ID.\n  * Each bucket contains field → value pairs.\n\nFor each strategy, two insertion modes were compared:\n\n1. **Single** – one record per transaction.\n2. **Bulk** – all records inserted in a single transaction.\n\nThis allows us to observe whether insertion method influences on-disk layout and subsequent performance.\n\n---\n\n## Tests Conducted\n\nFor each `(Strategy, Insertion Mode)` combination and database size `N`, the following tests were run:\n\n* **Read** – fetch `N/2` random records, one per transaction.\n* **ReadMany** – fetch `N/3` consecutive records from the midpoint, in a single transaction.\n* **FieldSum** – compute the sum of a single field by iterating over all records.\n* **Update** – update one field for `N/2` random records, one per transaction.\n* **Storage** – measure on-disk database size.\n\nAll performance results (except storage) are reported as **time per record**, calculated as total time divided by number of records.\n\n---\n\n## Results\n\n### Write\n\n![](./results/Write_time.png)\n\n**Test description**\nInsert records into the database.\n\n* **Single**: one record per transaction.\n* **Bulk**: all records inserted in a single transaction.\n\n**Analysis**\n\n* Inserting one record per transaction takes about 30–50 µs per record.\n  In a typical web server, transactions usually insert \u003c10 records, so performance will be closer to this case than to bulk.\n* Inserting all records in a single transaction takes \\~2–10 µs, except for NestedBucket and MultiKV.\n* Too many keys or nested buckets severely degrade performance:\n\n  * NestedBucket (Bulk): \\~50 µs/record (worst).\n  * MultiKV (Bulk): \\~32 µs/record, similar to JSON (Single).\n* Performance plateaus after \\~1k records, then slightly worsens as the B+-tree deepens.\n* Gob is consistently slower than JSON.\n* Binary+Names ≈ JSON.\n* Binary is the fastest.\n\n---\n\n### Read\n\n![](./results/Read_time.png)\n\n**Test description**\nRead `N/2` random records, one per transaction.\n\n**Analysis**\n\n* Gob is \u003e3× slower than JSON (the next worst).\n* Insert mode does not affect read performance.\n* MultiKV ≈ NestedBuckets, since each lookup involves at most one sub-bucket.\n* Binary is fastest.\n\n---\n\n### ReadMany\n\n![](./results/ReadMany_time.png)\n\n**Test description**\nRead `N/3` consecutive records starting from the midpoint, in a single transaction.\n\n**Analysis**\n\n* Gob is \\~3.75× slower than JSON.\n* Insert mode has no effect.\n* MultiKV and NestedBuckets diverge—NestedBuckets are penalized by sub-bucket indirection.\n* MultiKV ≈ Binary. Surprisingly, MultiKV outperforms Binary+Names even though both store field names.\n* Consecutive KV access is as efficient as tightly packed KV storage.\n\n---\n\n### FieldSum\n\n![](./results/FieldSum_time.png)\n\n**Test description**\nIterate over the entire database and compute the sum of a field, in a single transaction.\n\n**Analysis**\n\n* Gob remains the slowest.\n* NestedBuckets ≈ MultiKV ≈ Binary when scanning for a single field.\n* Binary performs as fast as MultiKV: deserializing the full record is cheap in this encoding.\n\n---\n\n### Update\n\n![](./results/Update_time.png)\n\n**Test description**\nUpdate a single field for `N/2` random records, one update per transaction.\n\n**Analysis**\n\n* Gob is \\~2× slower than the best encoding, \\~1.5× slower than the second worst.\n* MultiKV (Bulk) slightly outperforms Binary and NestedBucket at 1M records, though the difference is small.\n* Otherwise, Binary and NestedBucket are on par.\n\n---\n\n### Storage\n\n![](./results/storage_growth.png)\n\n**Test description**\nMeasure on-disk database size.\n\n**Analysis**\n\n* MultiKV and NestedBuckets are the least space-efficient (field names stored repeatedly).\n* JSON, Gob, and Binary+Names compress better because record count × field count amplifies overhead in MultiKV/NestedBuckets.\n* Binary is the most efficient: \\~2× smaller than the next best, \\~3× smaller than the worst.\n\n---\n\n## Conclusions\n\n* **Gob**: poor performance, similar space usage to JSON.\n* **NestedBucket / MultiKV**: worst write throughput and storage efficiency.\n* **JSON**: practical, balanced option for BoltDB.\n* **Binary+Names**: no real advantage over JSON; unnecessary.\n* **Best practice**: store most record data in a single KV pair, and extract only frequently updated fields into separate KV pairs.\n* **Maximum performance**: use compact binary encoding without field names.\n  For small records (≤200–300 B), the cost of re-serializing entire records is often lower than updating per-field in NestedBucket or MultiKV layouts.\n\n---\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fitsfarseen%2Fboltdb-benchmarks","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fitsfarseen%2Fboltdb-benchmarks","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fitsfarseen%2Fboltdb-benchmarks/lists"}