"Self-hosted platforms are slower than the big SaaS ones." It's a reasonable assumption and, on the operations that actually hurt, it turns out to be backwards. In VBWD's own load tests, the long, repetitive jobs that quietly punish a classic e-commerce stack — full catalogue synchronisation, bulk re-indexing, feed reconciliation — ran roughly 10 times faster than a conventional catalogue-first baseline. Here is why the architecture, not a magic trick, produces that gap.
What we measured
The benchmark targets the operations nobody demos but everybody runs in production: syncing a large catalogue, re-indexing after a bulk change, and reconciling third-party feeds. These are the jobs that lock up a store for minutes, spike a cloud bill, and get scheduled for 3am so customers don't notice. Indexed to a conventional platform at 100, VBWD completed the same catalogue-sync work at about 10 — an order of magnitude less wall-clock time on the exact workload that scales worst.
Why it's faster — the boring, real reasons
The speed isn't a tuned hot path; it falls out of the design:
- The catalogue isn't the spine. In a catalogue-first system, everything is modelled around a monolithic product table, so a bulk operation drags the whole object graph — variants, pricing, content, relations — through every pass. In VBWD the point of truth is the invoice line item, and the catalogue is one optional plugin, so a sync touches far less per record.
- Events, not full rewrites. The event-driven core lets a change propagate as a targeted event rather than a wholesale re-computation. You update what changed and emit an event; downstream reacts. That turns an O(everything) reindex into something much closer to O(what moved).
- You carry only what you enabled. Because capabilities are plugins that toggle without a restart, a deployment isn't hauling modules it never uses through every operation. Less surface in the request path means less work per pass.
Why 10x matters in money, not just seconds
A ten-fold cut in long-operation time is not a vanity metric. Long jobs are where cloud spend concentrates — CPU-minutes, database load, the oversized instance you keep "just for the nightly sync." Cutting that by an order of magnitude is directly lower hosting cost, and, incidentally, lower energy use: a leaner machine is a greener one. It also changes what's possible operationally — a sync that took ten minutes and had to run overnight can run in one and happen on demand.
The honest caveat
This is a benchmark of specific long-running operations, not a blanket claim that every request is 10x faster. Results vary by workload, data shape and hardware, and a single fast page load won't feel different. The point is narrower and more useful: on the heavy, repetitive jobs that punish catalogue-first architectures, designing around the invoice and the event bus instead of the product table pays off by roughly an order of magnitude — and those are exactly the jobs that drive your infrastructure bill.
The platform is source-available, so you can run the numbers yourself. Read the documentation, clone the public SDK at github.com/VBWD-platform/vbwd-sdk-public, or get in touch.
VBWD is source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay under the value of 6.7 BTC per year.