[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fX11B7JXvkfMKCv450YyEpUx6n_etj9qhX_j6fyAa0jw":3},{"id":4,"title":5,"slug":6,"excerpt":7,"contentMarkdown":8,"contentHtml":9,"coverImage":10,"tags":11,"status":15,"publishedAt":16,"author":17,"readingTimeMinutes":18,"seo":19,"createdAt":23,"updatedAt":23},"6a08a325b35e61ba9ea7a904","Where do you put JSON? I benchmarked three databases to find out.","where-to-put-json-database-benchmark","My bachelor's thesis pitted MySQL, PostgreSQL, and MongoDB against 100,000 JSON documents. The interesting question wasn't which won — it was where each one broke.","# Where do you put JSON? I benchmarked three databases to find out.\n\nIf you've worked on a backend in the last decade, you've had this argument:\n\n\"Just put it in Mongo.\"\n\"No, modern Postgres handles JSON fine.\"\n\"MySQL has JSON columns now too.\"\n\nFor my bachelor's thesis, I tried to settle it — with a stopwatch and a memory profiler instead of opinions.\n\n## The setup\n\nI built an automated benchmarking app in Python that ran the same CRUD workload (insert, read, update, delete) against MySQL, PostgreSQL, and MongoDB. Two scenarios: a small JSON document and a large one. Volumes scaled up to 100,000 records. PyMongo, Psycopg, and MySQL Connector did the talking; Python's standard *time* library kept score.\n\nThe goal wasn't to declare a winner. It was to find where each one breaks.\n\n## What broke first\n\n- **MySQL** was fine on small data. The moment documents got large and volumes grew, both speed and memory degraded fast. Both axes failed it simultaneously.\n- **PostgreSQL** held up far better than I expected. It was *fastest on insert* by a wide margin, came out on top in several other operations too, and tracked MongoDB on memory at every scale. The lazy \"modern Postgres handles JSON fine\" take turned out to be largely true.\n- **MongoDB** still won the most consistent overall story — strong on most operations and the lowest memory footprint at 100,000 documents. But the clear margin was against MySQL, not PostgreSQL: against Postgres the gaps were often slim. The trick is BSON: storing JSON as binary means it never has to parse the document just to read a field.\n\n![Bar chart titled \"Ustvarjanje\" (Creating\u002FInserting) comparing insert time for small and large JSON documents across MySQL, PostgreSQL, and MongoDB — PostgreSQL is fastest at 19.46 s and 32.17 s, while MySQL takes 60.18 s and 194.49 s and MongoDB 86.89 s and 98.25 s (chart from the original thesis, axis labels in Slovenian).](https:\u002F\u002Fkjjl82lign75qi0t.public.blob.vercel-storage.com\u002Fuploads\u002F1778878679721-uOLdi8kC7g.jpg)\n\n![Line chart of memory consumption in kilobytes as the dataset grows from 10³ to 10⁵ JSON documents across MySQL, PostgreSQL, and MongoDB — MySQL pulls upward and away from the other two as volume scales (chart from the original thesis, axis labels in Slovenian).](https:\u002F\u002Fkjjl82lign75qi0t.public.blob.vercel-storage.com\u002Fuploads\u002F1778878678388-Rf6-618bFX.jpg)\n\nThe narrative \"SQL vs NoSQL\" wasn't the useful one. PostgreSQL tracked MongoDB on most metrics; MySQL was the clear outlier.\n\n## Why this still matters\n\nJSON-shaped data is now everywhere — APIs, events, logs, user-generated content. Where you put it is a five-year cost decision: latency compounds across millions of requests, and memory bills compound faster.\n\nIf you're picking a database for JSON-heavy workloads today, this is the test I'd run before reading another comparison article: pull 100,000 representative documents from your real domain, time the four basic operations, watch the memory curve, and let the numbers argue.\n\n## What it taught me\n\nThree things I still use every week:\n\n1. **Measure your own workload.** Generic benchmarks lie to you in the only direction that matters.\n2. **The interesting question is \"where does it break?\" — not \"which is fastest?\"** Breaking points are what your future on-call self will thank you for knowing.\n3. **Binary beats text** for anything you'll write more than you'll read by hand.\n\nThis was my first real engineering project. Five years later, the specific numbers are obsolete — but the lens it gave me, *measure first, opinions later*, is still how I make every infrastructure call.\n\nIf you want the full version — methodology, every chart, the testing app, the raw measurements — the [full bachelor's thesis is archived at the University of Maribor](https:\u002F\u002Fdk.um.si\u002FIzpisGradiva.php?lang=slv&id=80055) (in Slovenian).\n\n---\n\nWhat's your default for JSON-heavy workloads today, and what would actually change your mind?\n\n#MongoDB #PostgreSQL #MySQL #NoSQL #DatabaseDesign #BackendEngineering #JSON\n","\u003Ch1>Where do you put JSON? I benchmarked three databases to find out.\u003C\u002Fh1>\n\u003Cp>If you’ve worked on a backend in the last decade, you’ve had this argument:\u003C\u002Fp>\n\u003Cp>“Just put it in Mongo.”\n“No, modern Postgres handles JSON fine.”\n“MySQL has JSON columns now too.”\u003C\u002Fp>\n\u003Cp>For my bachelor’s thesis, I tried to settle it — with a stopwatch and a memory profiler instead of opinions.\u003C\u002Fp>\n\u003Ch2>The setup\u003C\u002Fh2>\n\u003Cp>I built an automated benchmarking app in Python that ran the same CRUD workload (insert, read, update, delete) against MySQL, PostgreSQL, and MongoDB. Two scenarios: a small JSON document and a large one. Volumes scaled up to 100,000 records. PyMongo, Psycopg, and MySQL Connector did the talking; Python’s standard \u003Cem>time\u003C\u002Fem> library kept score.\u003C\u002Fp>\n\u003Cp>The goal wasn’t to declare a winner. It was to find where each one breaks.\u003C\u002Fp>\n\u003Ch2>What broke first\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>MySQL\u003C\u002Fstrong> was fine on small data. The moment documents got large and volumes grew, both speed and memory degraded fast. Both axes failed it simultaneously.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>PostgreSQL\u003C\u002Fstrong> held up far better than I expected. It was \u003Cem>fastest on insert\u003C\u002Fem> by a wide margin, came out on top in several other operations too, and tracked MongoDB on memory at every scale. The lazy “modern Postgres handles JSON fine” take turned out to be largely true.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>MongoDB\u003C\u002Fstrong> still won the most consistent overall story — strong on most operations and the lowest memory footprint at 100,000 documents. But the clear margin was against MySQL, not PostgreSQL: against Postgres the gaps were often slim. The trick is BSON: storing JSON as binary means it never has to parse the document just to read a field.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cimg src=\"https:\u002F\u002Fkjjl82lign75qi0t.public.blob.vercel-storage.com\u002Fuploads\u002F1778878679721-uOLdi8kC7g.jpg\" alt=\"Bar chart titled "Ustvarjanje" (Creating\u002FInserting) comparing insert time for small and large JSON documents across MySQL, PostgreSQL, and MongoDB — PostgreSQL is fastest at 19.46 s and 32.17 s, while MySQL takes 60.18 s and 194.49 s and MongoDB 86.89 s and 98.25 s (chart from the original thesis, axis labels in Slovenian).\" loading=\"lazy\" \u002F>\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"https:\u002F\u002Fkjjl82lign75qi0t.public.blob.vercel-storage.com\u002Fuploads\u002F1778878678388-Rf6-618bFX.jpg\" alt=\"Line chart of memory consumption in kilobytes as the dataset grows from 10³ to 10⁵ JSON documents across MySQL, PostgreSQL, and MongoDB — MySQL pulls upward and away from the other two as volume scales (chart from the original thesis, axis labels in Slovenian).\" loading=\"lazy\" \u002F>\u003C\u002Fp>\n\u003Cp>The narrative “SQL vs NoSQL” wasn’t the useful one. PostgreSQL tracked MongoDB on most metrics; MySQL was the clear outlier.\u003C\u002Fp>\n\u003Ch2>Why this still matters\u003C\u002Fh2>\n\u003Cp>JSON-shaped data is now everywhere — APIs, events, logs, user-generated content. Where you put it is a five-year cost decision: latency compounds across millions of requests, and memory bills compound faster.\u003C\u002Fp>\n\u003Cp>If you’re picking a database for JSON-heavy workloads today, this is the test I’d run before reading another comparison article: pull 100,000 representative documents from your real domain, time the four basic operations, watch the memory curve, and let the numbers argue.\u003C\u002Fp>\n\u003Ch2>What it taught me\u003C\u002Fh2>\n\u003Cp>Three things I still use every week:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Measure your own workload.\u003C\u002Fstrong> Generic benchmarks lie to you in the only direction that matters.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The interesting question is “where does it break?” — not “which is fastest?”\u003C\u002Fstrong> Breaking points are what your future on-call self will thank you for knowing.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Binary beats text\u003C\u002Fstrong> for anything you’ll write more than you’ll read by hand.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>This was my first real engineering project. Five years later, the specific numbers are obsolete — but the lens it gave me, \u003Cem>measure first, opinions later\u003C\u002Fem>, is still how I make every infrastructure call.\u003C\u002Fp>\n\u003Cp>If you want the full version — methodology, every chart, the testing app, the raw measurements — the \u003Ca href=\"https:\u002F\u002Fdk.um.si\u002FIzpisGradiva.php?lang=slv&id=80055\" target=\"_blank\" rel=\"noopener noreferrer\">full bachelor’s thesis is archived at the University of Maribor\u003C\u002Fa> (in Slovenian).\u003C\u002Fp>\n\u003Chr \u002F>\n\u003Cp>What’s your default for JSON-heavy workloads today, and what would actually change your mind?\u003C\u002Fp>\n\u003Cp>#MongoDB #PostgreSQL #MySQL #NoSQL #DatabaseDesign #BackendEngineering #JSON\u003C\u002Fp>\n",null,[12,13,14],"databases","mongodb","postgresql","published","2026-05-16T17:02:30.003Z","goxkitech",4,{"metaTitle":20,"metaDescription":21,"ogImage":22},"Where do you put JSON? Three databases, one benchmark.","MySQL, PostgreSQL, and MongoDB benchmarked on 100,000 JSON documents — where each one breaks, and why \"SQL vs NoSQL\" is the wrong question.","https:\u002F\u002Fkjjl82lign75qi0t.public.blob.vercel-storage.com\u002Fuploads\u002F1778878678388-Rf6-618bFX.jpg","2026-05-16T17:02:29.995Z"]