An application setting called read only can sound like a complete permission policy. During database replacement, the buyer should establish what that setting actually does through the chosen client and what separately determines the identity’s permitted actions.
The question matters for reporting tools, support applications and AI services intended to inspect business records. A configuration label can be useful operating information, but it should not substitute for evidence of the access boundary the application requires.
Read the JDBC contract at the correct layer
The Java SE 25 JDBC Connection documentation describes the read-only setting as a hint to the driver for database optimization. That interface contract should be distinguished from a complete description of the database account’s privileges.
The buyer should ask how the selected driver and database implement the setting, including whether it establishes an enforced restriction in the intended workflow. The documented hint alone is insufficient evidence for every permission requirement.
This does not mean every driver ignores the setting, that enforcement is impossible or that every database feature named read only is advisory. The actual implementation and its scope need to be verified.
Identify the operation the application is meant to allow
Consider a hypothetical support tool whose service identity should inspect order records but should not change them. A project may enable an application read-only option and demonstrate a successful query.
That result establishes that the demonstrated read worked. It does not, by itself, establish which other actions the database identity can perform or which restrictions remain if the application takes another supported connection path.
The owner should state the intended access policy and identify which components enforce it. If a driver setting contributes to that policy, document its role alongside the account and application controls rather than treating the controls as interchangeable evidence.
Review the intended mode and the permission boundary
The proposed checklist separates related claims without prescribing a driver implementation.
| Review item | Question for the evaluator | Evidence to request |
|---|---|---|
| Application intent | What work should this service perform? | Approved operation scope |
| Driver behavior | What does the chosen setting change? | Version-specific implementation evidence |
| Database identity | What actions are permitted? | Reviewed account and access design |
| Application result | Does the intended boundary hold? | Controlled positive and negative checks |
A proposal should identify the actual client path used by the service. A test through an administrative connection should not be presented as proof of the reporting identity’s boundary, and a test through one driver configuration should not silently stand in for a different deployed configuration.
Rehearse the approved access boundary
A useful synthetic pilot checks a required read and a separately agreed excluded action using the intended application identity. The team should identify which component is responsible for the observed restriction and retain enough configuration context to explain the result.
The purpose is not to probe a live service with an unapproved write. The project should use an isolated environment and synthetic records under its accepted test plan. If the proposed boundary depends on driver behavior, the same driver version and relevant settings need to be represented in the rehearsal.
The team should also distinguish an application choosing not to expose an action from a database identity being unable to perform it. Both can be legitimate design decisions, but they answer different review questions. This article has not connected to a database, changed privileges or attempted an excluded operation.
Compare OceanBase with the actual client arrangement
OceanBase’s product overview presents a relational modernization option. A proposal should identify the supported connection arrangement and demonstrate the access behavior the application requires for the chosen product, version and driver.
A PostgreSQL or MySQL proposal should face the same service-identity and client-path checks. General SQL compatibility does not establish identical behavior for every JDBC option, and a standard method name does not remove the need for implementation evidence.
The buyer can compare the work required to preserve the existing application’s intended access boundary. Different implementations can be acceptable when their responsibilities are explicit and the required outcomes are demonstrated. The comparison should avoid awarding a security conclusion merely because a setting carries a reassuring label.
Accept the enforced boundary, not just the mode label
The handover should identify the application’s allowed work, selected driver behavior, database identity and results of the controlled access checks. It should explain which component provides each required restriction.
That makes database replacement easier to assess. OceanBase and mainstream alternatives can be evaluated on the application boundary they actually support, with the JDBC read-only hint retained in its documented role rather than treated as a universal permission certificate.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.