Courante SaaS: HeatWave or a Warehouse for Tenant Dashboards
Courante is a B2B SaaS vendor running a 3 TB MySQL 8.0 database on a single OCI MySQL DB System for 2,200 tenants. The OLTP path is healthy at 1,200 transactions per second, but the product team shipped a tenant-facing dashboard that runs GROUP BY and window-function queries over 18 months of order history. Those queries push the DB system's CPU to 95% for about 20 minutes after each login peak, and read replicas have only partially cut the reporting load because the heaviest queries still run on the primary. Two options are on the table: attach a MySQL HeatWave cluster, or stream changes with GoldenGate into Autonomous Data Warehouse and build the dashboards there. The team has strong SQL skills but no Oracle Database experience, and finance will not fund both. Executive reporting also needs to join SaaS data to finance data that already lives in an Oracle 19c ERP.
1. HeatWave or GoldenGate into ADW? Make the call and state the test that would reverse it.
Read the worked answer
Start with the deciding question: must the ERP join be live in the same dashboard as the tenant metrics? That, not product preference, determines the answer.
- If the executive report is monthly or daily, MySQL HeatWave wins. It accelerates the exact MySQL queries the team already writes - no ETL, no second SQL dialect, no Oracle skills, and no new failure mode where a pipeline lags. The 20-minute CPU spike after login peak is precisely an offload problem, and HeatWave moves those GROUP BY and window functions to a separate cluster without consuming DB system CPU.
- If executives need a live join between SaaS orders and Oracle ERP finance data, HeatWave cannot do it. That is a cross-engine query, and GoldenGate into ADW is the only single-product answer, with tenant dashboards also pointed at ADW.
The test that reverses the call: ask whether the ERP join is a real-time requirement or a monthly close artefact. If it is the latter, it does not justify rebuilding the dashboard stack, and a small scheduled extract satisfies it.
2. What must be true of the schema and the cluster before HeatWave delivers the CPU relief the team expects?
Read the worked answer
Three checks, in order, before anyone buys nodes:
- Engine and types. HeatWave accelerates InnoDB tables only. MyISAM tables, and columns of types outside the supported list, are not loaded - queries touching them fall back to the DB system, producing partial relief that looks like a sizing problem. Audit the top 20 dashboard tables for engine, character set and column types first.
- Working set versus cluster memory. The cluster must hold the columns the queries touch. Three terabytes of InnoDB does not mean three terabytes of accelerated data - a 500 GB set of order-history and dimension columns may be all that is required - but an undersized cluster stops offloading silently and CPU returns to 95%. Size from the columns actually referenced, then add tenant-growth headroom.
- Load and DDL behaviour. The cluster populates from the DB system and refreshes after changes; bulk loads and schema changes still hit the source. If the login peak coincides with a nightly load, offloading queries will not fix that window.
Validate with query plans that show secondary-engine use and with per-query HeatWave metrics before declaring success.
3. What would make you reconsider the HeatWave decision on isolation or cost grounds?
Read the worked answer
Reconsider if any of these holds:
- Noisy-neighbour fairness. The dashboard serves 2,200 tenants from one cluster. One tenant's 18-month scan can crowd out the rest. Tenant-predicate enforcement, per-tenant limits or a queue may be needed, and none of that comes free with the cluster.
- Cost curve. HeatWave is billed by cluster node-hours and runs continuously. If the only pain is a 20-minute spike, a 24x7 cluster is a poor trade against ADW serverless, which idles near zero and scales into the spike.
- History depth. If dashboards will eventually need five years while MySQL keeps 18 months, an offload cluster does not solve it; a warehouse with retention does.
The anti-pattern to name explicitly: buying HeatWave to fix a connection storm. If CPU correlates with logins rather than query volume, check connection pooling and max_connections - the queries were never the problem, and the cluster will not fix it.