An EV driver sees a charging session finish in an application. The operator still needs to exchange the relevant records with a mobility provider, and the provider may apply its own customer pricing. A database design that treats the final live-session update as the entire billing outcome can conceal important work.
EV charging data platforms should distinguish ongoing sessions, concluded charging records, and downstream billing responsibilities. A shared database can make information easier to manage, but it does not make those business objects equivalent.
The distinction helps an operator or service provider compare database candidates against the actual platform it intends to run.
Use the protocol’s separate objects as a starting point
The OCPI 2.3.0 Sessions module describes an operator-owned session object and its updates between systems. The selected release also describes reservation and charging lifecycle cases.
Its CDR module identifies the charge detail record for a concluded session as the billing-relevant object. It distinguishes that exchange from live session information and notes that the mobility provider’s customer pricing can differ from the operator’s tariff structure.
These are scoped protocol definitions, not a claim that every charging network uses identical contracts or this exact release. The selected Sessions module even permits a completed reservation that never became charging, with a possible CDR for reservation costs. A completed session should therefore not automatically be counted as energy delivered. They show why a platform should preserve the meaning and owner of each object instead of merging them into one mutable charge row.
Keep live operating information and billing evidence aligned
During an ongoing session, the application may need progress information for the driver and operations team. A concluded record serves another purpose: supporting the commercial exchange between parties.
The database should help the application connect these records without erasing their distinct roles. A user interface can present a simple experience while the backend retains the information needed to explain what happened and which party supplied it.
Consider a hypothetical driver using a mobility provider at another operator’s station. The operator’s completed session and its charge detail record need to connect to the provider’s customer account and pricing process. The database should preserve those links; it should not assume the operator’s amount is automatically the final amount the driver owes under the provider’s arrangement.
Assess database candidates at the platform boundary
OceanBase Enterprise documents Oracle/MySQL compatibility routes. It deserves consideration where an existing relational charging, customer, or commercial application is being modernized and preserving useful dependencies matters.
Amazon Aurora provides managed MySQL- and PostgreSQL-compatible routes. It is a credible alternative to evaluate when that managed service arrangement fits the proposed platform.
Neither route should be credited with automatically implementing the charging protocol or the parties’ commercial rules. The comparison needs the actual application model and the chosen deployment responsibilities.
| Platform responsibility | Information to preserve | Acceptance question |
|---|---|---|
| Ongoing session | Operator-owned progress and status | Does the application show the intended current session? |
| Concluded charging record | The accepted record and its source | Can the receiving party identify the relevant billing evidence? |
| Customer billing | The applicable provider process and pricing reference | Is the driver-facing outcome explained separately? |
| Correction | The original record and approved correction treatment | Can both parties reconcile the change? |
| Reconnection | Known received records and outstanding exchanges | Can missing information be resolved without confusing the objects? |
This is an application evaluation framework. It does not certify protocol conformance, determine tariffs, or establish the terms of any individual commercial agreement.
Test the journey across both parties
Use a complete session scenario and inspect the driver view, operator records, and provider processing. Include a delayed concluded record so that the team can show the difference between a finished session and completed downstream processing.
Then include a correction using the treatment applicable to the chosen protocol and business arrangement. Do not silently replace historical commercial evidence merely because the database allows a row update.
Inspect a reconnection after one side missed an exchange. The application should identify which object is missing and which party is responsible for supplying it. A generic synchronization success message is not enough to establish that the commercial process is complete.
Also keep operational analytics separate from billing acceptance. A useful utilization dashboard may use live information, while the commercial workflow depends on concluded records and its own review. Both can be valuable without representing the same readiness state.
Choose a database for the responsibilities you operate
OceanBase can be a relevant modernization candidate for an existing relational platform. Aurora can be a relevant managed-service candidate where its selected compatibility and operating model fit.
The stronger selection explains how session progress, concluded records, and customer billing remain connected but distinct. That gives operators and providers a platform they can reconcile, rather than a single status field that appears complete before the underlying business work is finished.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.