From T+1 to Real Time: Rethinking Transactional and Analytical Workloads

When Detection Comes Too Late

At 3 p.m., a suspicious pattern of fund transfers appeared in a bank's transaction system: multiple small payments were sent from different accounts into one account and then quickly transferred out. The pattern matched a common money-laundering technique known as structuring, where large transactions are broken into smaller ones to avoid reporting thresholds or detection rules.

Yet the risk and compliance team could not act in time.

The problem was not that the activity had gone unrecorded. It was that the analysis was not ready. The detection logic depended on analytical tables generated by T+1 batch processing. At that moment, the analytics system could only work with yesterday's data. The suspicious activity from that afternoon would not show up in reports until the next morning. By then, the funds might already have moved through several more accounts, making them harder to trace.

The next morning, the report was generated as scheduled. The risk and compliance team confirmed the suspicious activity and launched an investigation. But after an overnight delay, the consequences had already become much more serious:

• Regulatory accountability: Why was the suspicious activity not intercepted when it occurred?
• Compliance risk: Failure to report suspicious transactions within the required time window may lead to regulatory penalties.
• Harder fund recovery: The funds had already passed through multiple accounts, making recovery far more costly and difficult.

The same problem appears far beyond financial services. Retailers often rely on yesterday's sales reports. Manufacturers analyze data from the previous production cycle. Internet platforms often have to wait until batch processing is complete before key business metrics become fully available.

The common issue is clear: transaction systems record data in real time, but analytical systems often deliver results only after overnight processing. The data already exists, but it cannot be used when decisions actually need to be made.

Why does analytics often fall one step behind transactions? Is there an architecture that allows transactions and analytics to run on the same data, within the same system, so that risk management workflows, operational analytics, and operational dashboards no longer have to wait for T+1?

Why Analytics Always Runs a Day Behind

Across different business scenarios, the impact of data latency varies. But the root cause is often the same architectural problem: transactions and analytics are split across two separate systems, with ETL pipelines moving data between them. As a result, analytics can only be as fresh as the synchronization and batch-processing pipeline allows.

Scenario 1: Compliance and Risk Management — Delayed Decisions, Uncontrolled Risk

Anti-money laundering, fraud detection, and payment risk management share one defining characteristic: the moment a transaction occurs is often the best time to assess and respond to risk. Once that moment is missed, the cost of remediation rises sharply.

In a traditional architecture:

• Online checks run on the TP database, while rule-based analysis runs on the AP database. The transactional database handles real-time recording and queries, while the analytical database handles large-scale scans, aggregations, and rule matching. Data is synchronized between them through ETL.
• After a suspicious transaction occurs, analysis results may not be available until the next day. If a suspicious transaction happens at 3 p.m., the system may not detect it until the next morning's batch processing is complete. During those hours, the funds may have moved through additional accounts, making investigation and recovery more difficult.
• Running analytics directly on the TP database is not practical. TP databases are typically row-oriented and optimized for point queries and small updates, not large-scale scans and aggregations. Forcing analytical workloads onto the transaction database can slow down online transactions.

The delay is built into the architecture. Data becomes available overnight, but suspicious activity can spread in real time.

Scenario 2: Operational Analytics — Delayed Reports, Slower Decisions

Asset-liability management in banking, retail sales analysis, and manufacturing cost analysis all require managers to work with up-to-date data. Yet in traditional architectures, many daily business, sales, and cost reports are essentially based on yesterday's data.

• Core transaction data resides in the TP database, while analytical wide tables reside in the AP database. Data must be moved across systems, which creates long pipelines, increases latency, and may introduce inconsistencies.
• Managers see a historical snapshot, not the current state of the business. A daily report viewed in the morning typically includes data only up to midnight. If market conditions, inventory, channels, or cash flow have changed during the morning, the report no longer reflects the latest business conditions.
• Pushing analytical queries onto the transaction database can affect core operations. Scans and aggregations over tens of millions of records may significantly increase transaction response times. Many enterprises want real-time analytics, but they cannot allow analytical workloads to interfere with online transaction processing.

As a result, managers make decisions based on yesterday's data, even when the business has already changed. This makes it harder to respond quickly and accurately.

Scenario 3: Hybrid Workloads — Transactions and Analytics Compete for Resources

Real-time e-commerce dashboards, real-time game analytics, and multi-tenant SaaS queries all share one characteristic: transactional and analytical queries coexist, often on the same business data.

In traditional architectures, enterprises typically handle this problem in one of three ways:

• Run analytics on the TP database. Large-scale scans can increase transaction latency. During a major sales campaign, a single real-time operational analytics query may cause order writes to queue up and payment requests to time out.
• Try to handle transactional workloads in the AP system. Analytical databases are optimized for batch scans, but they are not designed for high-concurrency small transactions.
• Let both workloads share the same resources. Transactions and analytics compete for CPU, memory, and I/O. Both workloads can suffer: transactions become less responsive, while analytical queries take longer to finish.

The reason is simple: transactions and analytics need different data access paths. Row stores are better suited to point queries and small updates, while column stores are better suited to large-scale scans and aggregations. When a single storage format is used for both workloads, performance trade-offs are almost unavoidable.

Three Scenarios, One Root Cause

These scenarios look different on the surface, but they share the same architectural bottleneck: traditional TP+AP architectures rely on two separate systems and ETL-based data movement, making it difficult for analytics to move beyond T+1 latency. At the same time, a single storage format can rarely provide the optimal access path for both transactional and analytical workloads.

Enterprises are often caught in a trade-off: maintain separate TP and AP systems with T+1 latency, or run transactions and analytics on shared infrastructure where workloads may interfere with each other.

OceanBase HTAP offers a third option: within the same cluster, table-level storage formats allow transactions and analytics to each use the access path best suited to their workload.

The Fix: One System, Two Access Paths

Traditional TP+AP architectures depend on data movement. Transactions are first written to the TP system, then extracted, transformed, and loaded into the AP system for analysis. This pipeline takes time, often runs overnight, and may introduce consistency issues. Running analytics directly on the transaction database is not a practical alternative, because large analytical queries can consume resources needed by online transactions.

HTAP changes this model. Within the same OceanBase cluster, the row-store path supports high-concurrency transactions, while the column-store path supports large-scale analytics. Data no longer needs to be copied into a separate analytical system before it can be analyzed. Once transaction data is written, it can become available for analysis within the same cluster.

Running transactions and analytics in one system is not just a deployment change. It changes how business data is used. Transactions and analytics no longer have to coordinate across two copies of data, two systems, and two pipelines. Instead, they work on the same source data within the same cluster.

OceanBase's table-level storage formats provide workload-specific access paths at the database layer. For different business tables, users can choose row store, column store, or hybrid row-column store, allowing different workloads to use the access path best suited to them.

Scenario 1: Compliance and Risk Management — Row Store for Online Checks, Column Store for Rule-Based Analysis

Online checks use the row-store path, which is well suited to high-concurrency point queries and status updates. Suspicious transaction analysis uses the column-store path, which is better suited to large-scale scans, rule matching, aggregations, and feature calculations.

The key is that the data comes from the same source and remains within the same cluster. Data generated by online transactions can be accessed directly by analytical queries in the same cluster, without being moved to another system through ETL. In suitable scenarios, data latency can be reduced from T+1 to seconds or near real time, allowing risk and compliance teams to trigger analysis and response shortly after a suspicious transaction occurs.

Risk and compliance teams no longer have to wait for overnight data processing. After a suspicious transaction occurs, rule matching and risk analysis can be completed more quickly, and compliance response is no longer constrained by T+1 reporting.

Scenario 2: Operational Analytics — Row Store for Transaction Writes, Column Store for Analytical Queries

Core transaction tables use row store to ensure write and point-query performance. Analytical wide tables, summary tables, or reporting base tables use column store to improve scan and aggregation efficiency.

Because transactions and analytics run in the same cluster, analytical queries can work with fresher business data instead of relying only on overnight batch results. Operational analytics can shift from post-event review to more timely decision support.

Managers can make more timely decisions about inventory, channels, cash flow, and sales strategies based on more up-to-date data.

Scenario 3: Hybrid Workloads — Hybrid Row-Column Store, Two Access Paths for One Table

Some tables need to support both high-concurrency transactions and analytical queries. For example, an e-commerce order table must handle real-time order placement, payment, and status updates, while also supporting real-time operational dashboards.

For such tables, OceanBase provides a hybrid row-column storage format. The same table can have both row-store and column-store access paths: transaction requests use the row-store path, while analytical queries use the column-store path.

Transactions are less likely to be affected by analytical workloads, while analytical queries no longer have to wait for T+1 data. The two workloads can coexist in the same system, without requiring multiple data pipelines for the same business table.

Core Value: Single Source of Truth, Real-Time Analytics, and Workload-Specific Access Paths

Across the three scenarios, the value comes down to three points:

1. Single source of truth: Transactions and analytics run within the same cluster, reducing the latency and consistency issues caused by cross-system ETL.
2. Real-time analytics: Analytical latency can be reduced from T+1 to seconds or near real time, so decisions no longer have to lag behind transactions by default.
3. Workload-specific access paths: Transactions use the row-store path, while analytics use the column-store path, allowing each workload to use the storage format best suited to it.

What You Actually Gain

The table above is the short version; two rows are worth expanding.

Data freshness is the dimension that changes daily work. For risk and compliance teams, it shortens the gap between a suspicious transaction and its analysis. For operations, it replaces a midnight snapshot with a current view of inventory, sales, cash flow, and channel performance.

Architecture complexity is the quieter win. With one system instead of a TP database, an AP database, and ETL in between, a broken report no longer starts with the question every on-call engineer dreads: is the problem in the source, the pipeline, or the target query?

Consistency, cost, and analytical performance all trace back to the same root cause — fewer redundant copies of data moving between systems — and the storage-cost side of that trade-off is covered in detail below.

Where HTAP Earns Its Keep

Scenario 1: Compliance and Risk Management

Requirement: Anti-money laundering, fraud detection, and similar scenarios require real-time or near-real-time screening of suspicious transactions, while also supporting retrospective analysis over large volumes of historical data.

Traditional challenge: The online database and reporting data warehouse are separated, resulting in long pipelines and high data latency. After a suspicious transaction occurs, the analysis report may not be available until the next day, increasing compliance risk and making fund recovery more difficult. If analytical workloads are forced onto the online database, large-scale scans may slow down transaction performance.

OceanBase solution: Online checks use the row-store path to ensure high-concurrency point queries and status updates. Rule-matching wide tables and feature aggregations use the column-store path to support large-scale scans and aggregations. Data stays in the same cluster and comes from the same source, reducing ETL-based data movement.

Value: In suitable scenarios, data latency can be reduced from T+1 to seconds or near real time. Batch analysis for anti-money laundering scenarios can be completed faster. Risk and compliance teams no longer have to wait overnight, and suspicious transactions can become available for analysis much earlier than in a T+1 pipeline.

Scenario 2: Operational Analytics

Requirement: Core transaction processing and operational analytics need to coexist. Managers want fresher data instead of relying only on yesterday's reports. At the same time, analytical workloads should not significantly affect transaction performance, and analytical queries still need to run efficiently.

Traditional challenge: Core databases and analytical databases are separated, resulting in high data movement costs and long latency. Forcing analytics onto the transaction database slows performance. Continuing to rely on the analytical database means accepting T+1 reporting latency.

OceanBase solution: Core transaction tables use row store to ensure write and point-query performance. Analytical wide tables use column store to ensure scan and aggregation efficiency. Data can be queried in near real time within the same cluster, while reducing the impact of analytical queries on transaction processing.

Value: Operational analytics moves from T+1 toward near real time. The impact of analytical queries on transaction processing is reduced, and the overall architecture becomes simpler. Managers can make decisions based on data that is closer to the current business state.

Scenario 3: Hybrid Workloads

Requirement: The same table needs to support both high-concurrency transactions and analytical queries. For example, an e-commerce order table needs to handle real-time order placement, payment, and status updates, while also powering real-time operational dashboards.

Traditional challenge: Row stores are slow for analytics, while column stores are not suitable for high-concurrency small transaction writes. Splitting the data into two tables and synchronizing between them puts enterprises back into an ETL-based architecture with data movement and consistency challenges.

OceanBase solution: Use hybrid row-column storage. The same table provides two access paths: transaction requests use the row-store path, while analytical queries use the column-store path. Each workload uses the access path best suited to its needs.

Value: Transactions and analytics can work on the same table without additional table splitting, system splitting, or complex synchronization pipelines for real-time analytics.

Is HTAP Right for You?

When HTAP Makes Sense

HTAP may be a good fit in the following situations:

1. Your TP and AP workloads already run on separate systems. Transaction and analytical databases are separated, data latency is typically T+1, and ETL pipelines are complex and costly to troubleshoot.
2. Your business requires real-time or near-real-time analytics. Risk and compliance workflows require seconds-level response, operational analytics needs to reflect current business conditions more closely, and operational dashboards need to reflect changes with minimal delay.
3. Hybrid workloads coexist. The same business involves both transactional and analytical queries. Pushing analytics onto the transaction database affects performance, while splitting systems introduces synchronization latency.
4. You want to simplify the architecture and reduce the operational, governance, and resource costs caused by ETL pipelines, multiple databases, and redundant data.

Choosing the Right Table Storage Format

OceanBase provides three table-level storage formats. Each format is designed for a different type of workload:

The Catch: Storage Cost and Where HTAP Stops Making Sense

The core value of HTAP is that business data can support both transactions and analytics within one system, reducing the cost of maintaining two systems and complex synchronization pipelines. But before adoption, enterprises need to evaluate two things carefully: storage cost and applicability boundaries.

Storage Cost: The Space Trade-Off for Real-Time Querying

To allow transactional and analytical workloads to each use the right access path, additional storage structures are often required. Different options have different storage overhead and suitable scenarios:

When evaluating storage cost, enterprises should not look only at the "extra copy of column-store data." They should also compare it with the total cost of maintaining a separate analytical system, ETL pipelines, redundant data, and reconciliation processes. For most enterprises that need real-time analytics, HTAP's value is not that it has "no cost," but that it trades predictable storage overhead for a simpler architecture and fresher data.

Applicability Boundaries: HTAP Is Not the Default Answer for Every Scenario

HTAP is suitable for scenarios where real-time analytics are clearly needed and both transactional and analytical workloads revolve around core business data. But this does not mean every table should enable column store or hybrid storage.

• Be cautious with column store or hybrid storage in extremely high-frequency write scenarios. Column store is better suited to batch scans and analytical queries. For core transaction tables with extremely high write throughput and limited analytical demand, row store should remain the first choice.
• Hybrid row-column storage introduces dual maintenance overhead. If a table has very high write volume and complex analytical queries, hybrid storage may add noticeable write pressure. In such cases, consider a row-store primary table plus a column-store auxiliary table, or other more fine-grained options.
• Analytics latency should be evaluated against business requirements. HTAP can typically support seconds-level or near-real-time analytics. However, if the business requires millisecond-level analytical responses with strict consistency guarantees, such as certain reconciliation scenarios, the specific mechanism and query routing strategy should be evaluated.
• DDL changes should be planned as part of implementation. Starting from version 4.3.5, converting a row-store table to a column-store or hybrid row-column table supports online asynchronous changes without blocking business writes.
• Avoid HTAP where there is no analytical demand. If the business has almost no analytical requirements, or existing analytical latency is already acceptable, enabling HTAP may only add storage and operational complexity.

Summary: Calculate the Trade-Off Before Adoption

HTAP still involves trade-offs. But for enterprises with real-time analytical needs, its value often outweighs the cost:

• Storage overhead is predictable and plannable. The key is to trade storage space for architectural simplicity, data freshness, and system unification.
• Limitations are real. Extremely high-frequency writes, millisecond-level strongly consistent analytics, and pure transaction workloads with no analytical demand all require careful evaluation.
• The practical rule is to choose storage formats at the table level. First analyze the access patterns of each table, then choose row store, column store, column-store index, hybrid row-column store, or C replica. Avoid enabling HTAP across the board.

From Yesterday's Reports to Real-Time Insight

Traditional architectures face a familiar dilemma: transactional (TP) and analytical (AP) systems are separated, and data must be moved through ETL before it can be analyzed. As a result, analytics often remains locked into a T+1 cycle. If analytics are forced onto the transaction database, core transactions may slow down. Enterprises are often forced to choose between delayed decisions and degraded performance.

OceanBase HTAP provides a third path through table-level storage formats: transactions use the row-store path, while analytics use the column-store path. Both workloads operate in the same cluster, on the same source data, with access paths suited to their needs. Risk analysis no longer needs to wait for overnight analytical tables. Suspicious transaction analysis can be triggered earlier. Business decisions no longer have to rely only on yesterday's reports. Hybrid workloads can use different access paths on the same table.

Business data should not become useful only after overnight processing. Decisions should not lag a day behind transactions. With HTAP, enterprises can keep transactions and analytics closer together — on fresher data, in one system, with access paths suited to each workload.

Want to try this on your own tables? With OceanBase Community Edition you can spin up a cluster and switch a table between row, column, and hybrid storage to see the trade-offs firsthand — see the OceanBase documentation to get started.