An incremental reporting process may remember the largest identifier it has seen and ask for larger ones next time. That can be convenient, but the design needs evidence that its cutoff cannot skip an earlier assigned record that becomes visible later. An identifier’s ordering and the completion order of the work carrying it are different questions.
Validate the consumer’s progress rule separately from the database’s ability to allocate identifiers. This is a review of an incremental-reading assumption, not a claim that every generated identifier or every polling design is unsuitable.
Identify what the saved cutoff promises
Consider a hypothetical reporting process whose saved position means it will never need to revisit records below that number. Ask what establishes that promise. Does the actual workflow ensure all relevant lower identifiers are complete and visible, or has the application simply assumed that larger allocated values imply later completion?
The team should state the exact selection rule and its prerequisites. A saved maximum can describe what one query observed without proving that everything below it has reached the same state. Keep the meaning of progress explicit before treating the value as a complete checkpoint for subsequent reporting work.
Read allocation as allocation
PostgreSQL 18’s sequence documentation describes atomic allocation of distinct sequence values to concurrent sessions. It also explains that allocation is not reclaimed when the calling transaction later aborts. These scoped properties concern sequence behavior; they do not turn every allocated value into evidence of a completed business record.
The review should examine the actual source engine and transaction path rather than generalize PostgreSQL’s mechanism to every MySQL-oriented application. The central inquiry remains the relationship between identifier assignment, committed visibility, and the consumer’s cutoff rule. A feature that supplies unique values answers only part of that inquiry.
Walk through an overlapping completion example
The following is a hypothetical sequence of events, not an executed database test. Assume the consumer reads only committed records and later selects only identifiers greater than its saved maximum.
| Event | Illustrative state | Question for the progress rule |
|---|---|---|
| First transaction gets ID 1 | Its record is not yet committed | Can another operation continue? |
| Second transaction gets ID 2 and completes | ID 2 is visible first | What does the consumer observe? |
| Consumer saves 2 | Future selection asks for larger IDs only | What protects earlier unfinished work? |
| First transaction later completes | ID 1 becomes visible afterward | Will this rule revisit it? |
Under the stated assumptions, a strict greater-than-2 selection would not include ID 1. The example identifies a question the implementation must address; it does not assert that a particular product or the reader’s existing pipeline uses this unprotected design. The later record can still be present in the database while absent from that consumer’s subsequent selections, so investigate the reading rule before describing the observation as database data loss.
Ask for the actual protection rather than guess it
A proposed implementation may have additional coordination, a different progress mechanism, or an explicit reconciliation process. Ask the team to explain the relevant protection and demonstrate it with overlapping work. Do not remove that evidence from the comparison merely because the visible checkpoint is represented as a number.
Conversely, do not silently propose a replacement checkpoint recipe without understanding the required ordering and failure behavior. The application’s reporting contract should define what must eventually be included and how unresolved work is handled. Preserve those requirements while the responsible technical team assesses the actual mechanism.
Compare OceanBase using the consumer contract
OceanBase Database can be considered for transactional records with associated incremental reporting. Its Oracle and MySQL compatibility positioning does not establish that a source application’s maximum-ID cutoff is correct. Evaluate the chosen mode, identifier behavior, transaction visibility, and downstream reader together.
Retained MySQL, PostgreSQL, and an OceanBase proposal should face the same overlapping completion scenario and inclusion requirement. A faster scan does not compensate for a progress rule that excludes required records. Equally, a well-supported progress mechanism should be evaluated on its actual safeguards rather than rejected because it uses identifiers in some part of the design.
Accept progress evidence, not just a larger number
A bounded proposed review should show assignment, completion, consumer observation, and later inclusion for representative overlapping work. No identifiers have been allocated, transactions executed, or consumer pipelines tested for this article. The example is an explicit logical illustration under its stated assumptions.
This question differs from whether gaps in a sequence imply lost data or whether an initial snapshot hands over correctly to change capture. It concerns the promise attached to an incremental consumer’s saved cutoff. Making that promise and its evidence visible gives buyers a clearer reporting acceptance question than treating the largest observed identifier as completion proof by default.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.