The scale test

A demo shop has forty products and no orders. A real shop has thousands of products and years of orders. Code that is comfortable on the first can fall over on the second, and the difference does not show up until you have customers — which is the worst possible moment to find it.

So we stopped testing on a demo.

What we loaded

A real production shop's data: a 410 MB database dump holding 66,701 orders, alongside its complete uploaded-files tree — around 900 MB and 5,000-odd images, the real product photos, banners and store logos.

That last part matters more than it sounds. Testing with an empty uploads folder means every image request 404s instantly, which is fast and tells you nothing. A shop's real media is part of its load.

The server: 4 GB of RAM, 2 CPU cores. Deliberately modest, because that is the size of box a shop actually starts on, and problems that only appear when resources are tight are exactly the problems worth finding.

What the scale revealed

Several things that were invisible on small data became obvious immediately:

• Pages that ran a database query inside a loop — fine at forty rows, catastrophic at thousands. The 8,614-questions earnings report on the measured results page is the extreme case, but it was not the only one.
• Queries with no index behind them, which a small table hides completely because scanning forty rows costs nothing.
• Listing screens that loaded every matching row into memory in order to show ten of them.
• A cache that kept a copy per unique request, which on a small catalogue is a handful of copies and on a real one is thousands.

None of these are exotic bugs. They are the ordinary consequence of code written and tested against a demo dataset, and they are precisely what a shop owner inherits on day one.

The number that says the most

After the work, the whole working dataset lived in memory: 99.99 % of database reads were answered without touching the disk, on a 515 MB dataset in a 1 GB buffer pool.

That is the real finding, and it is more useful than any single response time. It means the shop is not waiting on storage during normal operation — the pages are fast because the data is where it needs to be, not because one query got tuned.

Throughput, stated carefully

Under 20 concurrent users hitting the search endpoint for 30 seconds, the server sustained roughly 53 requests per second on 2 cores.

Read that as exactly what it says. It describes one endpoint, on this dataset, on two cores. It is not "6amMart does 53 requests per second" — a different screen or a bigger machine gives a different answer, and we did not measure a bigger machine.

Where the boundaries are

Two further honesty notes. Storage-speed figures from these runs are not usable as evidence — they reflect which physical host the virtual machine happened to land on, not the software. And the dataset, real as it is, is one shop: your catalogue's shape will differ, and shape affects which queries matter.

The database was a fifth bigger than it needed to be

Scale reveals size problems as well as speed ones, and this was the largest single thing found in the data itself rather than in a page.

6amMart saves a snapshot of the ordered item inside every order line, so an old order still shows what was actually bought at the price it was bought for. That is correct, and worth its storage. What went with it was not: the snapshot also carried a full copy of the module record the item belonged to — the module's description text and its translations — even though nothing anywhere reads that copy back.

On this shop's data, measured in August 2026:

| | | |---|---| | Item snapshots, in total | 226.9 MB | | Of that, the duplicated module record | 87.4 MB | | Order lines carrying it | 113,231 | | Distinct blocks of text among them | 42 |

Forty-two distinct blocks, stored a hundred and thirteen thousand times. It was 16 % of everything in the database, and the next largest field was fourteen times smaller — so this was one thing to fix, not a list.

Removing it, with the space then reclaimed by rebuilding the table:

Nothing was lost. Order lines still show the item as it was ordered; the fields the apps actually read — which module an item belonged to, and of what type — are plain values that sit beside the removed copy and were never touched. Anything that genuinely needs the module record reads the live one, which is one step away. The pass over all 113,231 rows took nine seconds, and every row was checked afterwards: still valid, still carrying its name, still carrying its module.

Two things worth stating plainly about this figure. It is a native-runtime measurement on this box — the 515 MB dataset quoted earlier on this page is the same shop measured on the container runtime, on different hardware, and the two are not the same round. And a smaller database is not automatically a faster one: this work was about storage and backup size, and it is published as that rather than converted into a speed claim it did not earn.

The fix ships two ways, because most shops do not run our optimised code. Ours stops writing the duplicate at the source. A stock CodeCanyon shop keeps writing it with every new order — verified against an untouched v4.1 install, where the duplicate is 38 % of each order line — so for those shops SixPanel removes it every night instead, and its database page shows how much is waiting to go before it runs.

Why we keep the dataset

Every change since is re-measured against the same data. That is the only way a "faster" claim stays true over time rather than describing one afternoon — and it is how the defects were found in the first place, because a defect that only appears at scale needs scale to appear in.