News | GaP Solutions

Why Your POS Slows Down on a Saturday — and What We Did About It

Written by Cornelia Freysen | Sep 12, 2026, 11:25:36 AM

GaP Solutions rebuilt the database layer underneath EM Cloud™ and EM Pos™, moving from AWS RDS with MariaDB to Oracle MySQL HeatWave. The result: host processing times for concurrent transactions cut by around 50%, infrastructure costs down around 65%, and master product and price updates applied in half the time.

If you run a store, none of that is the interesting part. The interesting part is what it means when four registers are scanning at once on a Saturday morning, when you pull a margin report across twelve sites, and when a price file needs to land before you open.

This article explains what changed under the bonnet and, more importantly, what it changed at the counter.

WHAT THE MIGRATION DELIVERED

~50%
Reduction in host processing time for concurrent transactions
~65%
Lower database infrastructure cost than the previous setup
Faster master product and price release patching
Minutes
To stand up a new store on the platform

These are GaP Solutions’ own measured results from internal testing and production workloads, as reported in an Oracle/MySQL customer case study. They are not independent benchmarks, and results in any environment depend on workload, data volume and configuration.

What this actually means in your store

Database performance is an abstraction until it isn’t. Here is the translation:

The technical change What you notice
Concurrent transactions handled roughly twice as fast Registers, scales, self-checkouts and the back office all hitting the system at once during a trading peak, without the lag that used to build up
Improved storage I/O performance Reports that used to be a “run it and go do something else” job come back while you are still looking at the screen
Patching and price releases in half the time Master product updates and new price files land faster, so your shelf and register pricing is current sooner
Greater database stability Fewer outages. The queries that used to crash the old servers now run through
New tenants provisioned in minutes A new store, or an acquired site, can be brought onto the platform quickly instead of waiting on infrastructure
Around 65% lower infrastructure cost Cost that isn’t being spent on servers is available for product development instead

Why the database under your POS matters

Every scan, every price lookup, every stock movement, every invoice line and every report is a database transaction. In a single store that is a steady stream. In a multi-store group running registers, scales, self-checkouts, forecourt controllers and a back office simultaneously, it is thousands of them competing for the same resources at the same moment.

This is what “concurrency” means in practice, and it is where cloud retail platforms either hold up or don’t. A system can look perfectly quick in a demo and still crawl at 11am on a Saturday, because the demo was one user and Saturday is forty.

“Due to the multi-tenant nature of our SaaS product, the ability of our database management system to handle more transactions concurrently is paramount, especially when scaling out.”

John Goodacre, Founder, GaP Solutions

The problem we set out to fix

GaP Solutions’ retail software started on the MySQL Community edition. As the business grew and the product moved to the cloud, the platform ran on AWS with MariaDB behind it.

That setup ran into four problems, and they compounded:

  • Concurrency. Performance degraded during simultaneous database transactions, which showed up as slower query response times for retail clients — exactly when stores were busiest.
  • Stability. Corrupt indexes and memory issues were causing downtime on production workloads. Some queries reliably crashed the servers.
  • Cost. Operational costs were high, and rising with scale.
  • Support economics. Getting help meant navigating support tiers with upfront fees attached — a real friction cost when a production database is misbehaving.

Taken together, this is the kind of problem that quietly limits what a software company can promise its customers. You cannot commit to fast reporting and high availability on infrastructure that is unpredictable.

Why MySQL HeatWave

The selection criteria were speed, efficiency, reliability and cost. Several providers were evaluated, and the decision came down to internal testing rather than vendor claims — GaP measured the workloads that actually matter to retail customers and compared the results.

MySQL HeatWave on Oracle Cloud Infrastructure won on measurable performance against the existing AWS RDS and MariaDB setup, and on cost.

“OCI continues to offer more cost-effective MySQL solutions compared to other cloud service providers, while driving innovation and enhancing performance through software updates and allowing us to use new hardware architecture as it becomes available through Oracle’s hardware partners.”

John Goodacre, Founder, GaP Solutions

What changed after the migration

Speed under load. Host processing times for concurrent transactions dropped by approximately 50% compared with the previous AWS RDS and MariaDB environment. For a multi-tenant platform, that headroom is what allows more stores to run harder on the same infrastructure.

Stability. Downtime on production workloads reduced. The queries that had been crashing the old MariaDB servers now complete.

“So far, MySQL HeatWave has not failed us when it comes to stability in the cloud. Problematic queries that crashed our previous MariaDB servers are running smoothly in MySQL HeatWave.”

John Goodacre, Founder, GaP Solutions

Reporting and data throughput. Improved storage I/O performance made transactional data easier to work with at volume — which is what turns a nightly batch report into something a manager can run mid-shift and act on.

Speed to onboard. A new tenant can be provisioned in minutes, which matters more than it sounds.

“We are often faced with unexpected clients turning up at the last minute, and we need to move quickly to secure those deals. MySQL HeatWave on OCI infrastructure enables us to do this.”

John Goodacre, Founder, GaP Solutions

Support. The migration itself was guided by MySQL and Oracle support teams, and the ongoing support model changed character.

“With AWS, there were cumbersome support tiers, with upfront fees just to be able to seek help for a problem with a particular server. But with Oracle we just contact the representative directly and receive on-the-spot assistance.”

Isara Arunanondchai, DevOps Engineer, GaP Solutions

Cost. Around 65% lower than the previous AWS RDS and MariaDB arrangement, with additional savings on network fees and related database service costs.

Why a retailer should care who runs the database

When you choose a cloud POS and back-office platform, you are not only choosing the screens your team will use. You are inheriting decisions your vendor made about infrastructure — and you will feel those decisions on your busiest trading day, not on the day of the demo.

Worth asking any vendor, including us:

  • How does the system perform with every register, scale and self-checkout transacting at once?
  • What is your history of downtime, and what caused the last significant outage?
  • How long does a new site take to bring online?
  • How quickly do master product and price updates propagate?
  • Where is the data hosted, and what happens in a disaster?

EM Cloud™ and EM Pos™ run on the platform described above. GaP Solutions has been building retail technology since 1992, moving into back-office software in 1999 and point-of-sale in 2003, and the database migration is part of the same pattern — changing the foundations when the foundations become the limit.

Fast in a demo is easy.
Fast at 11am on a Saturday is the test.

Frequently Asked Questions

What database does EM Cloud™ run on?

Oracle MySQL HeatWave, running on Oracle Cloud Infrastructure. GaP Solutions migrated from AWS RDS with MariaDB after internal testing showed measurable performance and cost advantages for the kind of concurrent, multi-tenant workload that retail software generates.

What difference does the database make to a retailer?

It determines how the system behaves under load. Every scan, price lookup, stock movement and report is a database transaction, and in a busy store or a multi-store group thousands of them compete for the same resources simultaneously. Faster concurrent transaction handling means registers, scales, self-checkouts and the back office can all work at once without lag building up; better stability means fewer outages; faster patching means price and product updates land sooner.

How much faster is the platform after the migration?

Host processing times for concurrent transactions were reduced by approximately 50% compared with the previous AWS RDS and MariaDB environment, and master product update and price release patching now takes about half the time. These are GaP Solutions’ own measured results reported in an Oracle/MySQL case study, not independent benchmarks.

Why did GaP Solutions move away from AWS?

Four reasons. Performance degraded during concurrent database transactions, which slowed query response times for retail clients. Corrupt indexes and memory issues were causing downtime on production workloads. Operational costs were high and rising with scale. And the support model required navigating tiers with upfront fees before help could be sought on a specific server.

How long does it take to bring a new store onto the platform?

A new tenant can be provisioned in minutes. This matters for retailers opening a new site or acquiring an existing one, where the constraint should be your own readiness rather than waiting on infrastructure.

Are these figures independently verified?

No. They are GaP Solutions’ own measured results from internal testing and production workloads, published in an Oracle/MySQL customer case study. Oracle also publishes its own MySQL HeatWave benchmarks, which are vendor-sourced. Any performance figure depends on workload, data volume and configuration, so treat these as one organisation’s outcome rather than a guaranteed result.

What should I ask a POS vendor about performance and uptime?

How the system performs with every register, scale and self-checkout transacting simultaneously; their history of downtime and what caused the last significant outage; how long a new site takes to bring online; how quickly master product and price updates propagate; and where the data is hosted and what happens in a disaster. Ask for measured answers rather than demo impressions — a system with one user behaves nothing like a system with forty.

Sources

See how it performs with your trading pattern

Tell us how many registers, scales and sites you run and what your peak looks like. We’ll show you how EM Cloud™ and EM Pos™ behave under that load — not under demo conditions.

BOOK A DEMO

Or call 1300 722 289  ·  marketing@gapsolutions.com.au