OceanBase vs TiDB: The Technology Route Debate in Financial-Grade Distributed Databases

#

Core thesis

The competition between OceanBase and TiDB should not be reduced to:

“Which database is faster?”

The more meaningful question is:

“Which distributed database architecture is better suited to which financial workload?”

OceanBase emphasizes:

Financial-grade OLTP + strong consistency + Oracle/MySQL compatibility + integrated distributed architecture

TiDB emphasizes:

MySQL compatibility + compute-storage separation + elastic scaling + HTAP + cloud-native operations

Both solve problems that traditional single-node databases struggle with:

• Horizontal scalability
• Distributed transactions
• High availability
• Multi-replica durability
• Disaster recovery
• Large-scale data

But they solve those problems in fundamentally different ways.

This makes OceanBase vs TiDB an important architectural debate:

Financial-Native Distributed Database

                   vs.

Cloud-Native Distributed SQL

The answer is not “winner versus loser.”

The answer is:

Architecture must match workload.

1. Why Are OceanBase and TiDB So Often Compared?

#

The two systems overlap significantly.

Both provide:

• Native distributed architecture
• SQL databases
• MySQL ecosystem compatibility
• Horizontal scaling
• Replication
• Distributed transactions
• High availability
• Financial deployment capabilities
• Cloud-native deployment
• HTAP-related capabilities

But similar feature lists hide important differences.

The real differences appear in:

Architecture
    ↓
Consensus
    ↓
Transaction Model
    ↓
Storage Engine
    ↓
Compatibility Strategy
    ↓
Operational Model
    ↓
Financial Workloads

That is why the real debate is not simply:

OceanBase vs TiDB

but:

Two different philosophies for building distributed databases.

2. Origin Determines Architecture

#

The best way to understand the two products is to start with their origins.

2.1 OceanBase: Born From the De-IOE Journey

#

OceanBase is closely associated with Ant’s transition away from traditional centralized IOE infrastructure.

A simplified historical path is:

Traditional IOE Infrastructure

        ↓

Rapid Growth of Payment Workloads

        ↓

Centralized Database Pressure

        ↓

Distributed Database R&D

        ↓

OceanBase

        ↓

Financial-Grade Distributed Database

The source material emphasizes several milestones:

2009
OceanBase initiative

        ↓

2013
Last traditional small machine removed
from Alipay's infrastructure

        ↓

2017
Singles Day payment traffic reaches
hundreds of thousands of transactions per second

        ↓

2020
Major TPC-C benchmark record

        ↓

Expansion into banking, securities,
payments, and other financial workloads

The architectural DNA is therefore clear:

Solve extreme OLTP and financial correctness first, then generalize the platform.

3.2 TiDB: Born From MySQL Scaling Problems

#

TiDB started from a different problem:

How can very large MySQL workloads scale horizontally without forcing application teams to manually manage database sharding?

A typical legacy trajectory was:

MySQL

   ↓

Growing Dataset

   ↓

Larger Server

   ↓

Sharding

   ↓

Cross-Shard Complexity

   ↓

Operational Cost

TiDB’s answer was:

MySQL Ecosystem

      ↓

Distributed SQL

      ↓

Horizontal Scaling

Its architecture therefore places greater emphasis on:

• MySQL compatibility
• Elastic scaling
• Compute-storage separation
• HTAP
• Cloud-native operations

A useful shorthand is:

OceanBase was pushed by financial OLTP constraints; TiDB was pushed by distributed MySQL scalability.

4. The Genetic Difference

#

This difference has existed since the beginning.

5. OceanBase: Integrated Distributed Architecture

#

OceanBase follows a Shared-Nothing philosophy, while keeping SQL processing and storage closely integrated within OBServer nodes.

A simplified topology:

                    Application
                         |
                         v
                      OBProxy
                         |
          +--------------+--------------+
          |              |              |
          v              v              v
      OBServer       OBServer       OBServer
       Zone 1         Zone 2         Zone 3
          |              |              |
          +--------------+--------------+
                         |
                         v
                 Paxos Replication

Each OBServer can participate in:

• SQL processing
• Storage
• Transaction execution
• Replica management
• Resource scheduling

The fundamental idea is:

The database node is itself a complete distributed database building block.

6. Why Integrated Architecture Matters

#

6.1 Fewer Major Components

#

A highly integrated architecture can reduce the number of separately managed subsystems.

That affects:

Deployment
    ↓
Configuration
    ↓
Monitoring
    ↓
Troubleshooting

This can be valuable in financial institutions with strict operational requirements.

6.2 Stronger Data Locality

#

SQL and storage are colocated within the same distributed database architecture.

The path is closer to:

SQL
 ↓
Transaction
 ↓
Storage

rather than forcing every operation through multiple independently scalable layers.

For transaction-heavy workloads, locality can matter.

6.3 Shorter Integrated Transaction Paths

#

OceanBase can be viewed as:

A database engine that also provides the distributed transaction infrastructure required by financial OLTP.

This is an important philosophical distinction.

7. OceanBase and Multi-Paxos

#

A core part of OceanBase’s architecture is its Paxos-based replication model.

A partition may have multiple replicas:

Partition

+-----------+-----------+-----------+
| Replica A | Replica B | Replica C |
+-----------+-----------+-----------+
        \          |          /
             Majority

A majority must confirm persistence before the operation becomes durable according to the configured consistency model.

The resulting design emphasizes:

• Strong consistency
• Replica-based fault tolerance
• Cross-zone durability
• High availability

This is highly aligned with financial workloads.

8. Why Strong Consensus Is Important in Finance

#

Financial databases often need:

Multiple Nodes
+
Multiple Zones
+
Multiple Replicas
+
Strong Consistency

If:

Replica A
   X

other replicas can continue participating in the system.

This is especially attractive for:

• Core banking
• Payment
• Clearing
• Securities
• Account systems
• Financial ledgers

The key point is not that Paxos is inherently “better.”

The point is:

OceanBase’s implementation was designed around strong-consistency distributed OLTP from the beginning.

9. OceanBase Multi-Tenancy

#

Another important architectural characteristic is native multi-tenancy.

Conceptually:

OceanBase Cluster

├── Tenant A
│   ├── CPU
│   ├── Memory
│   └── Storage
│
├── Tenant B
│   ├── CPU
│   ├── Memory
│   └── Storage
│
└── Tenant C
    ├── CPU
    ├── Memory
    └── Storage

This is valuable for financial institutions because a large institution rarely operates just one database workload.

A typical organization may have:

Core Trading
+
Accounts
+
Clearing
+
Risk
+
Channels
+
Management

Resource isolation and centralized governance therefore become important.

10. OceanBase Oracle + MySQL Compatibility

#

One of OceanBase’s major differentiators is its dual compatibility strategy.

The platform supports:

MySQL Mode

+

Oracle Mode

This is particularly significant for financial institutions with large Oracle estates.

A simplified migration path is:

Existing Oracle System
        |
        v
Application Assessment
        |
        v
OceanBase Oracle Mode
        |
        v
Distributed Financial Database

Oracle compatibility can reduce migration complexity involving:

• SQL syntax
• Stored procedures
• PL/SQL
• Data types
• Development practices

For organizations with a large Oracle footprint, this can be strategically important.

11. TiDB: Compute-Storage Separation

#

TiDB takes a very different architectural approach.

A simplified view is:

                     Application
                         |
                         v
                    TiDB Server
                  Stateless SQL Layer
                         |
             +-----------+-----------+
             |                       |
             v                       v
           TiKV                   TiFlash
        Row Storage             Column Storage
             |                       |
             +-----------+-----------+
                         |
                         v
                         PD
              Metadata / Timestamp

The architecture separates:

• SQL computation
• Row storage
• Column storage
• Cluster metadata and scheduling

This creates a fundamental characteristic:

Different dimensions of the database can scale independently.

12. Why TiDB Separates Compute and Storage

#

Suppose SQL workload grows rapidly:

TiDB Server

3
 ↓
6
 ↓
12

The compute layer can scale independently.

If data volume grows:

TiKV

3
 ↓
6
 ↓
12

storage can scale independently.

If analytical demand grows:

TiFlash

3
 ↓
6
 ↓
12

the analytical layer can scale independently.

This is the essence of:

Cloud-native elasticity.

13. TiDB’s Architectural Components

#

TiDB Server

#

Responsible for:

• SQL parsing
• SQL optimization
• Query execution
• Connections

The SQL layer is stateless.

TiKV

#

Responsible for:

• Row storage
• Persistence
• Raft replication
• Distributed transactional storage

TiFlash

#

Responsible for:

• Columnar storage
• Analytical workloads
• HTAP scenarios

PD

#

Responsible for:

• Metadata
• Scheduling
• Placement
• Global timestamps

A simple summary:

TiDB
=
SQL Compute

TiKV
=
Distributed Row Storage

TiFlash
=
Analytical Storage

PD
=
Control Plane

14. TiDB and Multi-Raft

#

TiDB’s storage consistency is based on Raft replication.

A simplified Region:

Region

+---------+----------+----------+
| Leader  | Follower | Follower |
+---------+----------+----------+

The Leader handles:

Read / Write

Followers replicate the state.

A majority of replicas must acknowledge writes before the operation can be committed.

Thus:

TiDB can also provide strong consistency in distributed transactional workloads.

It is therefore incorrect to characterize TiDB simply as an “eventually consistent database.”

15. Paxos vs Raft: Which One Is Better?

#

This question is much more complicated than:

Paxos > Raft

or:

Raft > Paxos

The actual system depends on:

Consensus Protocol
+
Storage Engine
+
Transaction Layer
+
Network
+
Scheduler
+
Failure Recovery
+
Hardware

Therefore:

The protocol name alone does not determine product performance.

An engineering implementation matters more than the theoretical label.

16. Distributed Transaction Models

#

OceanBase and TiDB also differ in how their transaction layers are organized.

OceanBase

#

A simplified model:

Global Timestamp

      ↓

Distributed Transaction

      ↓

Optimized 2PC

      ↓

Partition Commit

Single-partition transactions can use specialized optimizations to reduce coordination overhead.

This makes the architecture particularly suitable for:

• Core account systems
• Payment
• OLTP
• Financial transactions

TiDB

#

TiDB uses concepts derived from the Percolator transaction model.

A simplified path:

Start Timestamp
       |
       v
Read / Write
       |
       v
Commit Timestamp

Global timestamps are provided by the PD layer.

TiDB supports:

• Optimistic transactions
• Pessimistic transactions
• RC
• RR

This emphasizes general-purpose distributed SQL semantics while preserving strong transactional guarantees.

17. Transaction Model Comparison

#

18. Storage Engines: Two Different Answers

#

Storage architecture is another major difference.

18.1 OceanBase: Native LSM Architecture

#

A simplified model:

MemTable

   ↓

SSTable

   ↓

Compaction

This architecture provides:

• Efficient sequential writes
• Compression
• Incremental data handling
• Background compaction

OceanBase has also evolved toward tighter row-column integration.

18.2 TiDB: RocksDB + TiFlash

#

TiKV uses RocksDB as its underlying storage engine.

The write path can be simplified as:

MemTable

 ↓

WAL

 ↓

Raft

 ↓

Persist

TiFlash provides a separate columnar execution and storage path.

Data can therefore flow conceptually as:

TiKV

   ↓

Replication / Learner

   ↓

TiFlash

This creates a clean separation between:

OLTP

and

OLAP

19. HTAP: Two Different Design Philosophies

#

HTAP means:

Hybrid Transactional and Analytical Processing

The objective is to support:

OLTP
+
OLAP

without building completely disconnected data platforms.

OceanBase and TiDB take different approaches.

20. OceanBase HTAP: Integrated Row-Column Processing

#

OceanBase emphasizes a more integrated architecture:

Transactional Data

      ↓

Row / Column Capabilities

      ↓

Analytical Processing

The philosophy is:

Keep transaction and analytical capabilities closely integrated within one database architecture.

Potential advantages:

• Less duplicated data
• Lower storage overhead in some configurations
• Shorter paths between transactional and analytical workloads

21. TiDB HTAP: Dual Engines

#

TiDB uses:

TiKV

+

TiFlash

A simplified architecture:

                 TiDB
                   |
          +--------+--------+
          |                 |
          v                 v
        TiKV             TiFlash
       Row Store        Column Store
          |                 |
          +--------+--------+
                   |
               Same Data

This allows:

OLTP and OLAP resources to be isolated more explicitly.

The trade-off is additional infrastructure and replication.

22. HTAP Comparison

#

A simple way to remember it:

OceanBase: one system with multiple processing modes.

TiDB: one logical database with specialized storage engines.

23. Oracle vs MySQL: The Most Important Compatibility Question

#

For financial institutions, migration cost is often driven more by application compatibility than by raw database performance.

The key question is:

What database are you migrating from?

Oracle → OceanBase

#

Oracle
   ↓
Compatibility Assessment
   ↓
OceanBase Oracle Mode

This can significantly reduce migration work.

MySQL → TiDB

#

MySQL
   ↓
TiDB

This is one of TiDB’s strongest use cases.

Therefore a practical rule is:

Oracle-heavy financial core → OceanBase deserves serious evaluation.

Large MySQL workload → TiDB deserves serious evaluation.

This is a workload heuristic, not a universal rule.

24. Compatibility Comparison

#

25. Financial Deployment: OceanBase Strengths

#

Based on the source material, OceanBase’s financial deployments are concentrated around:

Core Accounting
+
Payments
+
Banking Core
+
Securities
+
Oracle Replacement

These workloads generally share:

• Heavy OLTP
• Strong consistency
• Large transaction volumes
• High availability requirements
• Multi-site disaster recovery

This aligns naturally with OceanBase’s original design philosophy.

26. Financial Deployment: TiDB Strengths

#

TiDB’s financial deployments highlighted in the source material emphasize:

Oracle / MySQL Migration
+
Horizontal Expansion
+
HTAP
+
Cloud Native

Representative categories include:

• Banking core systems
• Payment systems
• Accounting systems
• Financial channels
• Large data platforms

This demonstrates an important fact:

TiDB is no longer merely an Internet database.

It can also participate in financial-grade OLTP when properly engineered and deployed.

27. A Major Lesson From Banking Deployments

#

A modern bank may have:

Core Accounting
+
Payment
+
Risk
+
Channels
+
Data Analytics
+
Marketing

It is therefore unrealistic to assume that:

One database must solve every workload.

A more realistic architecture is:

                    Financial Institution

            +-----------+-----------+-----------+
            |           |           |           |
            v           v           v           v
          Core       Channels      Risk      Analytics
            |           |           |           |
            v           v           v           v
       OceanBase       TiDB        Other DB   Data Platform

This is:

Multi-database, workload-specific architecture.

28. Why “One Database for the Whole Bank” Is Not Always Desirable

#

Different workloads optimize for different characteristics.

The right question is not:

“Which database can do everything?”

It is:

“Which database gives the best operational and economic result for each workload?”

29. Performance: Why Benchmark Numbers Are Easy to Misuse

#

The source material contains various performance figures for both systems.

But raw benchmark numbers should not be compared without workload context.

A meaningful database benchmark must specify:

• Hardware
• Dataset size
• Transaction type
• Number of partitions
• Read/write ratio
• Query complexity
• Concurrency
• Failure conditions
• Network topology

For example:

TPS = X

means little without knowing whether the benchmark represents:

Single-Row OLTP

or:

Cross-Partition Transaction

or:

HTAP Mixed Load

Therefore:

Benchmark numbers must always be interpreted together with workload definitions.

30. What a Financial Database POC Should Actually Test

#

Financial institutions should test at least six dimensions.

OLTP

#

TPS
QPS
P99 Latency
P999 Latency

Distributed Transactions

#

Single Partition
Cross Partition
High Contention
Long Transaction

Failure

#

Node Failure
Zone Failure
Network Partition
Disk Failure

Disaster Recovery

#

RPO
RTO
Failover Time
Recovery Time
Data Verification

HTAP

#

OLTP

+

Concurrent OLAP

Migration

#

SQL Compatibility
Stored Procedures
Data Types
Character Sets
Application Changes

This gives a much more realistic decision framework than comparing headline TPS.

31. Disaster Recovery: Do Not Look Only at RPO and RTO

#

A database vendor may advertise:

RPO = 0

RTO < 30 seconds

But a financial institution needs to ask much more:

What happens during a zone failure?

What happens during a city-level failure?

What happens during network partition?

How is split-brain prevented?

What happens after failover?

How is application state recovered?

How is data verified?

Therefore:

Disaster recovery is an end-to-end system capability, not merely a database feature.

The full architecture includes:

Database
+
Network
+
Scheduler
+
Application
+
Operations
+
Monitoring

32. When OceanBase Is a Strong Candidate

#

OceanBase deserves strong consideration when the workload looks like:

Oracle Core
      ↓
Financial Core
      ↓
Strong Consistency
      ↓
High OLTP
      ↓
Multi-Tenant
      ↓
Complex Disaster Recovery

Typical scenarios include:

1. Oracle modernization
2. Core banking
3. Payment platforms
4. Securities core workloads
5. High-scale OLTP
6. Strong consistency financial systems

33. When TiDB Is a Strong Candidate

#

TiDB deserves strong consideration when the workload looks like:

MySQL
   ↓
Horizontal Scaling
   ↓
HTAP
   ↓
Cloud Native

Typical scenarios include:

1. Large MySQL workloads
2. Rapid data growth
3. HTAP applications
4. Kubernetes-native deployment
5. Distributed SQL platforms
6. Applications requiring strong MySQL ecosystem compatibility

34. A Third Option: Hybrid Database Architecture

#

Large financial institutions do not necessarily have to choose one database for everything.

A hybrid deployment could look like:

Core Accounting
      ↓
OceanBase

Digital Channels
      ↓
TiDB

Analytics
      ↓
TiDB / Lakehouse

Legacy Applications
      ↓
Oracle

Specialized Workloads
      ↓
Other Databases

The actual winning architecture may therefore be:

Multi-database collaboration rather than database monopoly.

35. “One Bank, Multiple Databases” Can Be a Feature

#

Multiple databases do not necessarily mean chaos.

If the institution provides:

Unified Governance
+
Security
+
Backup
+
Monitoring
+
Data Governance
+
Observability

different databases can be assigned to different workloads.

This creates:

Workload-driven database selection.

36. Five Major Dimensions of the Route Debate

#

36.1 Architecture

#

36.2 Consistency

#

36.3 Transactions

#

36.4 Storage

#

36.5 Ecosystem

#

37. OceanBase vs TiDB: The Architecture at a Glance

#

             OCEANBASE

Application
     |
   OBProxy
     |
+----+----+----+
|    |    |    |
OBServer nodes
|    |    |    |
SQL + Storage
     |
Paxos
     |
Distributed Data

versus:

                TIDB

Application
     |
TiDB Server
     |
+----+----------------+
|                     |
TiKV                TiFlash
Row OLTP            Column OLAP
|                     |
+----------+----------+
           |
           PD
     Metadata / TSO

The visual difference tells the story:

OceanBase integrates the database stack.

TiDB decomposes the database stack.

38. The Real Meaning of “Integrated vs Decoupled”

#

Integrated architecture optimizes for:

Locality
+
Simplicity
+
Transaction Path
+
Operational Cohesion

Decoupled architecture optimizes for:

Independent Scaling
+
Elasticity
+
Specialized Engines
+
Cloud-Native Operations

Neither philosophy is universally superior.

The right choice depends on what dominates the workload.

39. The Future: Both Products Are Moving Toward Each Other

#

The architectural gap is becoming less rigid.

OceanBase is expanding toward:

• Kubernetes
• Cloud-native deployment
• HTAP
• Vector capabilities
• AI workloads

TiDB is strengthening:

• Financial transactions
• Pessimistic locking
• Financial disaster recovery
• Core financial deployments
• AI and vector workloads

The evolution can be represented as:

OceanBase

Financial-Native
      ↓
Cloud-Native
      ↓
HTAP
      ↓
AI / Vector

and:

TiDB

Cloud-Native
      ↓
Financial-Grade Transactions
      ↓
Financial DR
      ↓
AI / Vector

40. The Emergence of a Third Architecture

#

The next generation of distributed databases may combine:

Strong Consistency

+

Elastic Scaling

+

HTAP

+

Vector Search

+

AI

+

Cloud Native

A conceptual architecture:

                      Application
                           |
                           v
                    Distributed SQL
                           |
             +-------------+-------------+
             |             |             |
             v             v             v
           OLTP          HTAP          Vector
             |             |             |
             +-------------+-------------+
                           |
                           v
                  Distributed Storage
                           |
                           v
                     Consensus
                           |
                           v
                    Cloud Native

This points toward:

AI-native distributed databases.

41. AI Will Change More Than Just Vector Search

#

It is tempting to think that AI databases simply mean:

Database
+
Vector Index

The larger transformation may be much broader.

Intelligent Querying

#

Natural Language

       ↓

SQL

       ↓

Query Optimization

Intelligent Operations

#

Metrics

   ↓

AI Diagnosis

   ↓

Root Cause

   ↓

Automated Remediation

Intelligent Data Platforms

#

Structured Data
+
Vector Data
+
Knowledge Graph
+
LLM

The database becomes:

An intelligent data infrastructure rather than merely a storage engine.

42. The Most Important Database Selection Questions

#

Before choosing between OceanBase and TiDB, a financial institution should ask:

1. What database are we migrating from?

2. Is the workload primarily OLTP or HTAP?

3. How important is Oracle compatibility?

4. How important is MySQL ecosystem compatibility?

5. How large is the dataset?

6. How large is transaction volume?

7. What is the transaction contention profile?

8. What disaster-recovery model is required?

9. Is Kubernetes a hard requirement?

10. What does the operations team know best?

Only after these questions are answered should product selection begin.

43. A Practical Decision Matrix

#

These scores are a conceptual selection framework, not a benchmark ranking.

44. One Sentence for Each Product

#

OceanBase

#

A financial-oriented distributed database that turns strong-consistency OLTP into a scalable distributed infrastructure.

Architecture:

Financial Core
    ↓
Strong Consistency
    ↓
High-Scale OLTP
    ↓
Oracle / MySQL
    ↓
Distributed Database
    ↓
Cloud Native

TiDB

#

A cloud-native distributed SQL platform that turns MySQL-style workloads into horizontally scalable, HTAP-capable infrastructure.

Architecture:

MySQL
   ↓
Horizontal Scaling
   ↓
Distributed SQL
   ↓
HTAP
   ↓
Kubernetes
   ↓
AI

45. Conclusion: The Debate Is Really About Workload, Not Winners

#

The question:

“Which is better, OceanBase or TiDB?”

has no universal answer.

The more useful question is:

What is the workload?

What is the source database?

What is the transaction model?

What is the scale?

What is the consistency requirement?

Do we need Oracle compatibility?

Do we need MySQL compatibility?

Do we need HTAP?

Do we need Kubernetes?

What disaster-recovery target do we have?

What can the operations team actually maintain?

The answers determine the product.

46. The Simplest Way to Understand the Two Routes

#

OceanBase

#

Financial Core

      ↓

Strong Consistency

      ↓

High-Performance OLTP

      ↓

Oracle Compatibility

      ↓

Distributed Database

      ↓

Cloud Native

TiDB

#

MySQL

      ↓

Horizontal Scaling

      ↓

Distributed SQL

      ↓

HTAP

      ↓

Kubernetes

      ↓

AI

This is why neither product is simply “better.”

They represent different starting assumptions.

47. The Real Technology Route Debate

#

The deeper competition is not:

OceanBase
vs
TiDB

It is:

Financial-Native Architecture

            vs.

Cloud-Native Distributed Architecture

And the industry is moving toward a convergence:

OceanBase
    |
    +--> Cloud Native
    +--> HTAP
    +--> Vector
    +--> AI

TiDB
    |
    +--> Financial Transactions
    +--> Financial DR
    +--> Financial Core
    +--> AI

The end state may be:

Strong Consistency
        +
Elastic Scaling
        +
HTAP
        +
Vector
        +
AI
        +
Cloud Native

or:

An AI-native distributed financial database.

48. Final Architecture Map

#

                         Financial Institution
                                  |
                    +-------------+-------------+
                    |             |             |
                    v             v             v
                  Core        Channels         Risk
                    |             |             |
                    v             v             v
               OceanBase        TiDB        Other DB
                    |             |             |
                    +-------------+-------------+
                                  |
                                  v
                           Unified Data Platform
                                  |
                     +------------+------------+
                     |            |            |
                     v            v            v
                   HTAP        Vector          AI
                     |            |            |
                     +------------+------------+
                                  |
                                  v
                           Cloud-Native Layer

Appendix: OceanBase vs TiDB Quick Reference

#

Author Note

Database selection becomes dangerous when a benchmark number is treated as the entire architecture.

A financial institution should not select a distributed database simply because:

TPS is higher

or:

MySQL compatibility is better

The real decision must include:

architecture, transaction semantics, consistency, compatibility, storage, HTAP, disaster recovery, cloud-native operations, migration cost, and team capabilities.

OceanBase and TiDB are not simply competing products.

They represent two different approaches to distributed database engineering.

OceanBase starts from financial-grade OLTP and expands toward cloud-native distributed infrastructure.

TiDB starts from cloud-native distributed SQL and expands toward increasingly demanding financial workloads.

That is why the long-term competition is so interesting.

As the two products continue to absorb each other’s strengths, the real target may no longer be:

“The best distributed database.”

It may become:

“The best AI-native financial data infrastructure.”

And that infrastructure will need to combine the four things that historically lived in different worlds:

financial correctness, cloud elasticity, HTAP capability, and AI intelligence.

That is the real technology race behind OceanBase vs TiDB.