An application can store several kinds of working data behind the same SQL interface. Some records represent accepted business commitments. Others are disposable intermediate results that the application can rebuild. A database selection should establish which kind each table contains before using a successful query as evidence of durable storage.
This distinction matters when comparing PostgreSQL, MySQL and an OceanBase proposal. The useful question is what must survive a particular interruption, together with what can be reconstructed and who owns that work. The presence of a table name does not answer it.
Read the table-specific persistence choice
The PostgreSQL 18 table documentation explains that unlogged tables do not send their data changes to the write-ahead log. Their contents are cleared after a crash or unclean shutdown and are not replicated to standby servers. This describes a particular table choice, rather than every PostgreSQL table or every orderly restart.
The MySQL 8.4 MEMORY documentation describes another specific choice: rows disappear when the server shuts down, while the table definition remains and the table is empty after restart. These two examples have different boundaries. They should not be reduced to a claim that all memory-oriented processing or all SQL storage behaves alike.
Separate a disposable result from an accepted commitment
Consider a hypothetical retailer using a working table to prepare a suggested replenishment list. If the table can be rebuilt from retained orders and stock records, losing the suggestion may be an accepted interruption. The team still needs to know how long rebuilding takes and whether staff can work during that period.
An accepted replenishment order has a different role. If the working table is the only place recording that order, calling it a cache does not make its loss harmless. The business classification must follow the actual information and downstream commitment, rather than the informal name developers gave the component.
This is an assessment example, not a report of a customer deployment. It also does not establish that either documented table choice is appropriate for the retailer.
Make persistence an explicit acceptance item
The proposed review below connects table purpose to the required evidence. It does not prescribe a storage setting.
| Data role | Acceptance question | Evidence to request |
|---|---|---|
| Accepted commitment | What must remain after interruption? | Agreed recovery result |
| Rebuildable calculation | Which retained inputs reproduce it? | Successful rebuilding exercise |
| Shared working data | Who can work while it is unavailable? | Defined service behavior |
| Migrated table | Was its persistence choice preserved or changed? | Approved destination mapping |
A migration can intentionally replace a disposable working table with durable storage, or redesign how an intermediate result is produced. Either decision should appear in the application scope and cost assessment. Treating the destination as equivalent without recording the change makes later operating surprises harder to explain.
Include rebuilding in the service test
A synthetic pilot should distinguish the presence of the table definition from the presence of its expected records. Reviewers should also see whether the application detects missing working data, reconstructs it from the intended inputs and avoids treating an empty intermediate result as a completed business outcome.
For the replenishment example, a page showing no suggestions immediately after recovery might mean that rebuilding has not finished. It need not mean that no stock needs replenishment. The product owner should decide what staff see during that interval and what evidence marks the calculation ready for use.
The exercise should follow an approved test plan in an isolated environment. This article does not interrupt a server, change logging or recommend testing failure against a live service. It identifies the outcome a proposal should demonstrate under its supported configuration.
Assess OceanBase against the required data role
OceanBase’s product overview presents a distributed relational platform for database modernization. That description is a reason to assess a proposed operating design, rather than evidence that every PostgreSQL or MySQL table option has an identical OceanBase counterpart.
A buyer should request the destination’s supported persistence behavior for the tables in scope. The comparison should include the business records that must survive, the intermediate data that can be rebuilt and the work required to preserve application expectations. PostgreSQL and MySQL proposals deserve the same table-specific assessment instead of being judged by an exceptional option as though it described the entire product.
Performance and capacity evidence should use the persistence policy the buyer has accepted. A quicker disposable calculation and a durable system of record may serve different purposes, even when both offer SQL access.
Approve the recovery contract alongside the schema
The final inventory should name each important table’s role, the interruption being considered, the required surviving information and any rebuilding owner. Changes to those expectations need an explicit acceptance decision.
This turns durability into a concrete selection criterion. OceanBase can be considered on the strength of its supported proposal, while PostgreSQL and MySQL retain their documented distinctions. A familiar query interface is useful, but the business also needs to know what remains when the service returns.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.