A database pilot can perform well during a short test without demonstrating the capacity the business can sustain through its normal operating cycle. When the test runs on burstable EC2 compute, its starting CPU credit balance and operating mode can be part of the explanation. The instance’s advertised processor count is not the whole test context.
For a database buyer, this is a comparison-quality issue. The goal is to understand the environment behind the result, rather than assuming that burstable compute is always unsuitable or that every cloud database uses the same credit mechanism.
Identify whether CPU credits apply to the test environment
AWS’s burstable-instance documentation describes a CPU baseline and credits used for activity above it. In Standard mode, depleted accrued credits limit further bursting and utilization moves toward the baseline. Unlimited mode has different surplus-credit and potential charging behavior.
These are EC2 instance characteristics, not a description of every AWS service or every database deployment. The buyer should first establish whether the actual pilot uses a supported burstable configuration and which mode applies. CPU credits are also distinct from promotional billing credits applied to an account.
Record the state at the beginning of the run
A test report should identify the compute configuration, credit mode and relevant starting balance where credits apply. Without that context, two runs on nominally identical instance types may be harder to interpret. A successful short run does not establish that the observed conditions will persist indefinitely.
Consider a hypothetical team that prepares its environment during a quiet period, then conducts a brief write-intensive demonstration. The result may accurately describe that run. The team should still ask whether the same configuration supports its longer business cycle, including the work that follows the demonstration.
This example is not a claim that a particular result was manipulated or that credits explain every performance change. It identifies one documented resource condition that belongs in the evidence.
Test the operating pattern the business intends to buy
The suggested checklist below focuses on reproducibility and interpretation. It does not prescribe an instance type or a universal test duration.
| Test context | Why it matters | Evidence to retain |
|---|---|---|
| Compute and mode | Defines the resource arrangement | Actual proposed configuration |
| Starting credit state | Identifies burst resources available initially | Relevant observed balance |
| Workload over time | Represents the business operating pattern | Results across the agreed run |
| Resource and cost outcome | Explains what sustained operation required | Observed utilization and applicable charges |
The workload should include the periods relevant to the buyer. A campaign service and a continuously busy processing service need not have the same utilization pattern. The conclusion should describe the tested pattern instead of turning one successful burst into a general capacity promise.
Keep performance interpretation separate from price assumptions
Unlimited mode should not be treated as an instruction to assume unlimited CPU at the base instance price. AWS documents conditions under which surplus usage can produce additional charges. The cost assessment should use the actual configuration, observed pattern and applicable offer, rather than a generic headline about low-cost burstable instances.
Standard mode presents a different question: whether its observed baseline and available credits fit the required service. A buyer may reasonably accept that arrangement for a suitable workload. The decision requires evidence about the intended operating cycle, not a blanket rule that every production database must use one compute family.
The test should also identify other resource limitations. A CPU-credit explanation should not replace investigation of storage, application behavior or query design when those are relevant. The purpose is to make the result more interpretable, not to declare the cause before measuring it.
Compare OceanBase using the actual supported proposal
OceanBase’s product overview presents a distributed transactional and analytical platform. When evaluating it on buyer-managed infrastructure, use the configuration supported for the proposed deployment and record the resource conditions of that test. This article does not establish support for a particular burstable instance or recommend one for OceanBase.
An Oracle, MySQL or PostgreSQL proposal should be assessed on a comparable basis where it is credible for the application. If one offer uses a managed service and another uses EC2, identify the difference rather than pretending both expose the same resource controls and billing terms.
A fair comparison can include different architectures if each is the actual proposal. What matters is that the accepted business workload, resource assumptions and continuing operating cost are explicit for each arrangement.
Accept the sustained service requirement
The final review should state what operating pattern was demonstrated, what resource state supported it and what that implies for the proposed service. It should avoid claiming that a short result establishes all-day capacity without the corresponding evidence.
CPU credits do not determine which database is best. They help define the environment in which a result was obtained. OceanBase merits evaluation when its complete supported proposal fits the workload, and that judgment is stronger when the pilot’s burst conditions are visible.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.