Database Types Explained: From OLTP and OLAP to HTAP, Vector Databases and OceanBase

Choosing a database often starts with the wrong question.

People ask which database is fastest, or whether they should use MySQL, PostgreSQL, MongoDB, Redis, TiDB, OceanBase, ClickHouse, or a vector database. Those products do different jobs. The terminology also mixes several different dimensions.

OLTP, OLAP, and HTAP describe workloads. Relational, document, and key-value describe data models. Row store, column store, and in-memory describe how data is stored and accessed. Distributed describes architecture. Vector describes another data and search capability. Structured and unstructured describe the data itself.

A database can belong to several of these groups at the same time. Calling OceanBase an “HTAP database” is therefore incomplete. OceanBase is a distributed relational database. It supports SQL, transactional work, analytical SQL, HTAP use cases, and MySQL-compatible environments. Current 4.x versions also document vector search, and V4.6.0 adds a SQL hybrid-search interface.

Those statements can all be true because they describe different parts of the system.

This guide starts from the beginning. By the end you should understand the major database categories, what problems they solve, where they overlap, and where OceanBase sits. You should also have a clearer idea of when not to use it.

Choosing the wrong database does not always fail immediately. Sometimes it works, but leaves the team operating complexity they never needed. Database selection should start with the workload, not with whichever architecture looks most impressive.

Understanding Database Types

What Is a Database?

A database stores information so that applications and people can retrieve and change it.

Take a payment application. We have customers:

Customer ID: 1001
Name: Somchai
Country: Thailand
Email: somchai@example.com

We have accounts:

Account ID: 50001
Customer ID: 1001
Currency: THB
Balance: 50,000

And we have transactions:

Transaction ID: 900001
Account ID: 50001
Type: PAYMENT
Amount: 1,000
Status: SUCCESS
Time: 2026-08-30 09:15:00

At very small scale, we could store this in files: one CSV for customers, one for accounts, one for transactions. That works until the system becomes real.

Two payments arrive at the same time. Someone updates an account while another process reads it. The application crashes halfway through transferring money. We need to search millions of transactions, let several applications connect at once, and keep backups, permissions, indexes, replication, and recovery. When the database says a payment was committed, that payment must still be there after a server failure.

That is the job of a database management system. A DBMS does more than store bytes. It manages how data is:

• organized
• queried
• modified
• protected
• shared
• indexed
• recovered
• replicated
• validated

Modern databases can also distribute information across many machines and coordinate transactions between them.

Why Database Terminology Becomes Confusing

One of the biggest problems when learning databases is that we use the phrase “type of database” for completely different properties.

These terms are not alternatives at the same level:

MySQL
OLTP
RDBMS
row store
distributed SQL
structured data
in-memory database
vector database
HTAP

A better way to organize them is to ask different questions.

What does the data look like?

Examples:

• structured
• semi-structured
• unstructured

How is the data modeled?

Examples:

• relational
• document
• key-value
• graph
• wide-column
• time-series
• vector

What workload are we running?

Examples:

• OLTP
• OLAP
• HTAP

How is the data physically accessed?

Examples:

• row-oriented
• column-oriented
• memory-oriented
• disk-oriented

How is the system deployed?

Examples:

• embedded
• single-node
• primary-replica
• clustered
• distributed

What does the application need?

Examples:

• transactions
• search
• analytics
• caching
• similarity search
• relationship traversal
• telemetry
• AI retrieval

Once we separate these questions, the categories stop colliding.

How Data Is Stored

Flat Files: Where Data Storage Often Starts

Before databases, we have files.

Create:

customers.csv

with:

customer_id,name,country,balance
1001,Somchai,TH,50000
1002,John,SG,10000
1003,Mei,MY,15000

This is structured information stored in a flat file. A program, spreadsheet, Python script, or shell filter can all read it. For many jobs, that is enough.

Common flat-file formats

Examples include:

• CSV
• TSV
• fixed-width files
• plain text
• simple JSON files
• log files

Flat files are useful for:

• exchanging data
• exports
• imports
• simple configuration
• small datasets
• batch processing
• logs
• temporary processing

Using a database where a CSV would be enough can be unnecessary.

The opposite is also true.

Using a CSV where you need a database can be dangerous.

What Goes Wrong With Flat Files?

If accounts.csv contains:

account_id: 101
balance: 50000

Two payment requests arrive.

Payment A wants to deduct 1,000.

Payment B wants to deduct 2,000.

Both applications read:

balance = 50000

Payment A calculates:

49000

Payment B calculates:

48000

Payment A writes its result.

Payment B then writes its result.

Final balance:

48000

But the correct balance should be:

47000

One payment effectively disappeared from the account balance.

A database has concurrency-control mechanisms intended to prevent this. A CSV file does not. At thousands of transactions per second, the file stops being a sensible system of record.

Structured Data

Structured data follows a defined format.

For example:

Each row follows a known structure.

The database knows that:

customer_id

is an identifier.

It knows:

balance

is numeric.

It can know that:

customer_id

must be unique.

Typical structured data includes:

• bank accounts
• orders
• invoices
• payment records
• inventory
• employees
• product catalogs
• airline bookings
• subscriptions
• accounting entries

Structured data maps naturally into relational tables.

Semi-Structured Data

JSON can look structured and still vary from record to record:

{
  "customer_id": 1001,
  "name": "Somchai",
  "preferences": {
    "language": "th",
    "notifications": true
  },
  "devices": [
    {
      "type": "iphone",
      "last_seen": "2026-08-30"
    }
  ]
}

There is clearly structure.

We have:

customer_id
name
preferences
devices

But every record does not necessarily contain exactly the same fields.

Another customer could have:

{
  "customer_id": 1002,
  "name": "John",
  "business_account": true
}

This is commonly called semi-structured data.

Examples include:

• JSON
• XML
• BSON
• event messages
• API payloads
• telemetry events

Document databases became popular partly because they make flexible structures convenient to store.

Modern relational databases also have strong JSON capabilities.

That means this assumption is outdated:

JSON = NoSQL

You can work extensively with JSON inside many relational systems.

Unstructured Data

These do not naturally fit a table:

• photographs
• videos
• audio
• PDFs
• Word documents
• emails
• scanned contracts
• CCTV recordings
• medical images
• support conversations

These do not naturally fit into a table such as:

id | name | amount | status

They are usually described as unstructured data.

That does not mean the files contain no technical structure.

A JPEG follows a file format.

A PDF has an internal format.

An email has headers.

What we mean is that their business content does not naturally map into a fixed table structure.

A common design is therefore:

Relational Database
        |
        +---- document_id
        +---- customer_id
        +---- filename
        +---- created_at
        +---- storage_path

Object Storage
        |
        +---- actual PDF/image/video

This is often better than forcing every file into the database itself.

Relational Databases and SQL

The Relational Database

Relational databases have been at the center of business computing for decades.

Examples include:

• MySQL
• PostgreSQL
• Oracle Database
• Microsoft SQL Server
• MariaDB
• IBM Db2
• OceanBase

The relational model organizes information primarily into tables.

customers

customer_id	name
1	Somchai
2	John

accounts

account_id	customer_id	balance
101	1	50000
102	2	10000

There is a relationship:

customers.customer_id
          |
          |
          +---- accounts.customer_id

We can query it:

SELECT
    c.name,
    a.balance
FROM customers c
JOIN accounts a
    ON c.customer_id = a.customer_id;

This ability to represent and query relationships is central to relational databases.

What Is an RDBMS?

RDBMS means:

Relational Database Management System

An RDBMS provides the software that manages relational data.

It normally handles things such as:

• tables
• indexes
• constraints
• transactions
• users
• permissions
• SQL execution
• concurrency
• recovery
• query optimization
• backups

MySQL, PostgreSQL, and Oracle Database are RDBMS products. OceanBase is also a relational database management system, although its underlying architecture is distributed. The distributed part comes later.

What Is SQL?

SQL stands for Structured Query Language.

SQL lets us tell the database what we want.

For example:

SELECT *
FROM transactions
WHERE account_id = 101;

Or:

SELECT
    country,
    SUM(amount)
FROM transactions
GROUP BY country;

SQL is a language, not a database. MySQL, PostgreSQL, Oracle, and OceanBase all understand SQL. They do not all understand every statement in the same way.

That shows up during MySQL to OceanBase migration. Official Community Edition documentation describes compatibility with most MySQL 5.6 and 5.7 syntax, plus some MySQL 8.0 features. The V4.2.1 compatibility notes describe compatibility with most features and statements of MySQL 5.7 or 8.0, then list remaining differences in data types, strings, PL, views, character sets, indexes, partitions, and backup.

Read the compatibility notes for the version you will run. Compatibility assessment and migration assessment are different jobs.

MySQL-compatible

does not mean:

identical to MySQL

and it does not mean a MySQL application can move with zero changes.

Transactions

Transactions are one of the ideas you cannot skip in databases.

Account A transfers 1,000 THB to account B. We need to debit A, credit B, and record the transfer. If the system debits A and then crashes, A has lost 1,000 THB and B never received it. That is unacceptable.

Instead, we use a transaction:

BEGIN;

UPDATE accounts
SET balance = balance - 1000
WHERE account_id = 101;

UPDATE accounts
SET balance = balance + 1000
WHERE account_id = 102;

INSERT INTO transfers (...)
VALUES (...);

COMMIT;

The intent is that these changes belong together.

Either the operation succeeds as a unit, or it does not.

This leads to ACID.

ACID Without the Textbook Language

ACID stands for:

• Atomicity
• Consistency
• Isolation
• Durability

You will see these four words everywhere.

Understanding them is more useful than memorizing them.

Atomicity

Think:

all or nothing

Our money transfer consists of multiple operations.

We do not want half the transaction committed.

Consistency

The transaction should preserve the rules of the system.

If a database has constraints and application rules, operations should move from one valid state to another valid state.

Isolation

Several transactions can happen at the same time.

The database needs rules controlling what those transactions can see and how concurrent modifications interact.

Put 100 people on the same inventory record. Without concurrency control, concurrent updates can overwrite each other or expose inconsistent results.

Durability

When the database confirms that a transaction has committed under its durability guarantees, the transaction should survive the failures covered by those guarantees.

If the payment API returns:

SUCCESS

and then the database loses the transaction because a server rebooted, we have a serious problem.

For a financial database, durability is not theoretical.

OLTP, OLAP and HTAP

What Is OLTP?

OLTP means:

Online Transaction Processing

The easiest way to understand OLTP is to think about applications doing normal business operations.

A customer buys something:

INSERT order
UPDATE inventory
INSERT payment
COMMIT

A player places a bet:

Read wallet
Create bet
Debit wallet
COMMIT

A bank transfer occurs:

Debit sender
Credit receiver
Create transaction
COMMIT

An ecommerce customer updates an address:

UPDATE customer

These are transactional operations.

OLTP systems commonly handle:

• many concurrent users
• many small transactions
• frequent INSERT
• frequent UPDATE
• frequent DELETE
• point reads
• short range reads
• relatively small result sets
• low latency requirements

OLTP is about running the business.

Typical OLTP Query

A table contains 500 million accounts.

The application asks:

SELECT balance
FROM accounts
WHERE account_id = 10001234;

It wants one balance, not all 500 million.

UPDATE accounts
SET balance = balance - 500
WHERE account_id = 10001234;

This write also targets very little data.

OLTP databases therefore care heavily about:

• indexes
• point lookups
• small writes
• locking/concurrency
• transaction processing
• predictable response time
• high availability

Databases Commonly Used for OLTP

Common choices include:

• MySQL
• PostgreSQL
• Oracle
• SQL Server
• MariaDB
• OceanBase
• TiDB
• CockroachDB
• YugabyteDB

These systems are not identical.

Some historically center around one primary database server.

Others were designed around distributed architecture.

Some support analytical workloads more extensively.

Calling all of them OLTP-capable does not mean their architectures are the same.

What Is OLAP?

OLAP means:

Online Analytical Processing

The same payment company now has ten billion transactions.

Management asks:

How much payment volume did we process by country, merchant category, currency and month during the last three years?

A query might look like:

SELECT
    country,
    merchant_category,
    currency,
    YEAR(created_at),
    MONTH(created_at),
    SUM(amount),
    COUNT(*)
FROM transactions
WHERE created_at >= '2023-01-01'
GROUP BY
    country,
    merchant_category,
    currency,
    YEAR(created_at),
    MONTH(created_at);

This is very different from:

SELECT balance
FROM accounts
WHERE account_id = 10001234;

The analytical query may scan millions or billions of records, then aggregate, group, and sort. That work can consume significant CPU, memory, and I/O. This is an OLAP-style workload.

OLTP vs OLAP

The simplest comparison is:

Neither is better. They are different jobs.

Why OLTP and OLAP Were Traditionally Separated

Production payments are running on a MySQL server. Customers are checking out, money is moving, and inventory is changing. An analyst then runs:

SELECT
    customer_id,
    SUM(amount)
FROM transactions
GROUP BY customer_id
ORDER BY SUM(amount) DESC;

across billions of rows.

That query consumes CPU, memory, storage I/O, cache, and temporary execution space. The production application is competing with analytics. If the analytical query slows payments, checkout latency rises and the operations team has to find the query while money is still moving.

This is one reason companies historically separate operational and analytical systems.

A common architecture is:

Applications
     |
     v
OLTP Database
     |
     | CDC / ETL
     v
Warehouse / OLAP Platform
     |
     v
BI / Analytics

Production stays focused on transactions.

Analytics runs elsewhere.

This architecture remains correct for many organizations.

What Is HTAP?

HTAP means:

Hybrid Transactional and Analytical Processing

The basic idea is:

OLTP + OLAP

on the same database platform.

Instead of always requiring:

Transaction DB
      |
      v
ETL / CDC
      |
      v
Analytics DB

some workloads may be served directly from an HTAP system.

Conceptually:

             Database
             /      \
            /        \
         OLTP        OLAP
            \        /
             \      /
               HTAP

This can be useful when organizations need analytical information close to current transactional data.

Why HTAP Exists

Fraud detection is a common example. Payments arrive continuously, and the fraud team needs to know what is happening now, not what happened six hours ago after the ETL job finished.

Similar requirements appear in real-time merchant dashboards, transaction monitoring, gaming activity, current account analysis, inventory, operational BI, risk scoring, and telecom billing. Reducing the delay between a transaction and analysis is the reason teams look at HTAP.

HTAP Does Not Mean Your Warehouse Is Dead

A company may have a warehouse combining data from:

Payments
CRM
ERP
Marketing
Support
Website
Logistics
Finance
External data

That is a much larger problem than analyzing one transactional database.

An HTAP system does not automatically mean:

Delete Snowflake
Delete BigQuery
Delete Redshift
Delete the data lake

It may reduce the need to copy operational data for certain use cases.

It may not replace enterprise analytics.

Architecture depends on the workload.

Anyone telling you that one database makes every other data platform unnecessary is probably simplifying the problem too much.

Row Stores, Column Stores and In-Memory Databases

Row-Oriented Databases

To understand why OLTP and OLAP behave differently, it helps to understand storage layouts.

A row-oriented layout conceptually stores related row values together:

1 | A | TH | 100 | PAID
2 | B | SG | 200 | PAID
3 | C | MY | 150 | FAILED

Now ask:

SELECT *
FROM transactions
WHERE id = 2;

We need the whole row.

Keeping row values together makes sense for transactional workloads.

Column-Oriented Databases

If the transaction table has 40 columns, an analytical query may want only:

country
amount

Reading every other column wastes resources.

A column-oriented layout conceptually keeps values from the same column together:

country:

TH
SG
MY
TH
TH
SG
...

amount:

100
200
150
80
500
...

The database can then focus on the columns required by the analytical query. Column-oriented storage also creates opportunities for effective compression because adjacent values may be similar.

Columnar systems are therefore strongly associated with analytics.

Examples include systems such as:

• ClickHouse
• Snowflake
• BigQuery
• Redshift
• Vertica
• Apache Doris

Implementation details vary, but the general idea is the same.

Row Store vs Column Store

Two queries want different things from storage.

Query A:

SELECT *
FROM orders
WHERE order_id = 12345;

Query B:

SELECT
    country,
    SUM(amount)
FROM orders
GROUP BY country;

Query A wants one complete row. Query B may examine millions of records but only two columns.

HTAP systems try to serve both patterns without forcing every workload through one storage behavior.

What Is an In-Memory Database?

Memory is fast.

Traditional persistent storage is slower.

An in-memory database is designed to keep all or a substantial amount of active data in memory so that operations can run with very low latency.

Redis is one of the best-known examples associated with in-memory processing.

Other systems make extensive use of memory as part of their design.

Common in-memory use cases include:

• caching
• sessions
• counters
• leaderboards
• temporary state
• low-latency lookups
• rate limiting

Why Not Put Everything in Memory?

Because memory has trade-offs.

RAM is:

• more expensive than persistent storage
• limited
• volatile unless durability is provided elsewhere

Store 100 TB purely in RAM and cost becomes the constraint, even though large memory systems can be built.

Durability also matters.

A financial platform cannot say:

We rebooted the server and today’s payments were in RAM, sorry.

Systems that use memory as primary storage need mechanisms such as:

• logging
• replication
• snapshots
• persistence

when the data must survive.

Database vs Cache

Application
     |
     +---- Redis
     |
     +---- MySQL

Redis may contain:

customer:1001:balance = 50000

for quick reads.

MySQL remains the authoritative source.

This is a cache architecture.

If Redis disappears, the application can reconstruct the cache from MySQL.

That is different from using Redis as the authoritative database itself.

Technology does not determine architecture on its own.

How the technology is used matters.

NoSQL Database Types

What Is NoSQL?

NoSQL is a broad category.

It includes several data models that do not follow the traditional relational-table model as their primary abstraction.

Common groups include:

• document
• key-value
• wide-column
• graph

NoSQL systems became popular for many reasons, including:

• flexible schemas
• horizontal scaling
• high write volume
• simple access patterns
• large distributed applications

But this statement is wrong:

NoSQL replaced SQL.

It did not.

Relational databases continued evolving.

Distributed relational databases appeared.

JSON support appeared in SQL databases.

Vector support appeared.

The boundaries became less clean.

Document Databases

Document databases store records as documents.

For example:

{
  "customer_id": 1001,
  "name": "Somchai",
  "addresses": [
    {
      "type": "home",
      "country": "TH"
    },
    {
      "type": "office",
      "country": "TH"
    }
  ]
}

MongoDB is the best-known example.

Document databases can work particularly well when:

• application objects map naturally to documents
• schemas change frequently
• nested information is common
• individual records can vary

They may be less natural when workloads consist heavily of complex relationships across many entities.

That does not mean modern document databases cannot perform transactions or relationships.

It means data modeling choices differ.

Key-Value Databases

A key-value system is conceptually simple:

key -> value

For example:

session:ABC123
    ->
{"user":1001,"expires":"10:30"}

Or:

product:5001:stock -> 27

If you know the key, retrieval can be extremely efficient.

Systems used in key-value patterns include:

• Redis
• DynamoDB
• Aerospike
• FoundationDB at its lower layer

Key-value models work well when access patterns are predictable.

They are less natural when you constantly need relational operations such as:

JOIN customer
JOIN merchant
JOIN country
GROUP BY month

Wide-Column Databases

Wide-column databases are built around column-family style models and are often used for very large distributed datasets.

Examples include:

• Apache Cassandra
• Apache HBase
• ScyllaDB

Typical strengths can include:

• high write throughput
• distributed deployments
• large datasets
• predictable query patterns
• sparse records

Designing these systems often requires thinking about the query first.

You model data around how the application will read it.

That is different from the normalized relational design many SQL engineers learn first.

Graph Databases

Some problems are primarily about relationships.

Account A
    |
sent money to
    |
Account B
    |
sent money to
    |
Account C

Or:

Person A -> OWNS -> Company A
Company A -> OWNS -> Company B
Person B -> DIRECTOR_OF -> Company B

Graph databases model:

nodes
+
edges

Relationships become first-class objects.

Examples include:

• Neo4j
• Amazon Neptune
• TigerGraph
• JanusGraph

Common applications include:

• fraud detection
• identity relationships
• social networks
• recommendations
• network topology
• knowledge graphs

You can represent graph relationships in relational databases. Graph-oriented technology is worth evaluating when traversal dominates the workload.

Search, Time-Series and Analytical Databases

Time-Series Databases

Some data is naturally organized around time.

Example:

09:00 CPU 42%
09:01 CPU 47%
09:02 CPU 63%
09:03 CPU 59%

Other examples:

stock price
sensor temperature
network latency
electricity usage
requests per second

Time-series databases optimize for:

• timestamped records
• high ingestion
• time windows
• retention
• aggregations
• downsampling

Examples include:

• InfluxDB
• TimescaleDB
• VictoriaMetrics
• QuestDB

Notice another overlap.

TimescaleDB builds time-series functionality around PostgreSQL. A system can be relational and time-series oriented at the same time. Categories overlap.

Search Databases

Sometimes the problem is not transactional lookup.

It is search.

For example:

Find all documents containing:
"OceanBase migration"

Or:

Search millions of logs for:
"connection timeout"

Systems such as Elasticsearch and OpenSearch are designed around search-oriented indexes.

They are widely used for:

• full-text search
• observability
• log analytics
• product search
• security events
• document retrieval

An architecture may therefore use:

Application
     |
     +---- PostgreSQL
     |
     +---- OpenSearch

PostgreSQL is the authoritative business database.

OpenSearch handles search.

That is not bad architecture.

Using more than one database technology is sometimes exactly the right choice.

Data Warehouses

A data warehouse is designed primarily for analytical workloads.

Common examples include:

• Snowflake
• Amazon Redshift
• Google BigQuery
• Teradata

A warehouse commonly collects information from many sources.

CRM ---------\
ERP ----------\
Payments ------> Warehouse -> BI
Website -------/
Support -------/

That is different from running analytics on the payment database.

Warehouses are often the central analytical system for an organization.

This is why HTAP and data warehousing are not necessarily competitors.

Data Lakes

A data lake is a broad repository that can contain large amounts of raw or processed information.

Commonly stored formats include:

• Parquet
• JSON
• CSV
• logs
• images
• machine-learning datasets
• event streams
• exports

Cloud object storage such as S3 often forms the underlying storage layer.

Unlike a traditional relational database, a data lake can store many kinds of information without first converting everything into relational tables.

Lakehouse

The lakehouse idea attempts to combine capabilities associated with warehouses with open storage formats and object storage.

Technologies in this area include:

• Apache Iceberg
• Delta Lake
• Apache Hudi

This area is mainly concerned with analytical data platforms.

It does not remove the need for transactional databases running applications.

Your payment API still needs somewhere reliable to commit a payment.

Vector and AI Databases

What Is a Vector?

Vectors became much more visible with modern AI applications.

An embedding model processes this sentence:

OceanBase distributed database

It may produce a numerical representation similar to:

[0.128, -0.443, 0.772, 0.091, ...]

Another phrase:

distributed SQL system

produces another vector.

If the meanings are similar, those vectors may be mathematically close.

This lets applications search for meaning rather than exact text.

What Is a Vector Database?

A vector database stores vectors and can efficiently search for similar vectors.

Traditional search might ask:

WHERE title = 'OceanBase'

Vector search asks something closer to:

Which stored objects are mathematically most similar to this query?

This can support:

• semantic search
• recommendation
• document retrieval
• image similarity
• duplicate detection
• RAG
• AI memory
• anomaly matching

Products strongly associated with vector workloads include:

• Milvus
• Qdrant
• Pinecone
• Weaviate

But vector search is no longer limited to specialist vector databases.

PostgreSQL can use pgvector.

Redis supports vector search.

Elasticsearch and OpenSearch provide vector capabilities.

OceanBase documents vector support in current 4.x editions. Hybrid search that combines vector and full-text retrieval is documented from V4.4.1, with a SQL HYBRID_SEARCH interface added in V4.6.0.

What Is an AI Database?

“AI database” is not a precise database architecture in the way relational database is.

It is increasingly used to describe databases that support data access patterns needed by AI applications.

That often includes:

• vector storage
• vector indexes
• similarity search
• full-text search
• hybrid search
• metadata filtering
• retrieval
• structured business information

OceanBase V4.6.0, for example, documents vector search and a SQL hybrid-search interface that can combine vector and full-text retrieval.

AI applications still need normal databases.

AI Does Not Replace Transactional Databases

Ask an assistant:

What is account 50001’s current balance?

Would you want the answer to come from an embedding that says:

This value is semantically similar to 50,000.

Of course not.

The account balance is exact.

Payments are exact.

Permissions are exact.

Invoices are exact.

Vectors are excellent for similarity.

They are not replacements for authoritative transactional values.

An AI application may therefore have:

                  AI Application
                   /          \
                  /            \
          Vector Search       RDBMS
               |                |
          documents          customers
          knowledge          accounts
          embeddings         payments
                             permissions

Sometimes one database can serve several of these roles. Sometimes separate systems are better.

Database Types Compared

OceanBase belongs in the relational row. It can also run analytical SQL, HTAP, and, in current 4.x versions, vector search. That does not make it the default choice in the other rows.

Scaling a Database

Single-Node Databases

A basic database architecture may be:

Application
     |
     v
MySQL Server
     |
     v
Disk

There is nothing wrong with this.

A well-configured MySQL or PostgreSQL database can support substantial workloads.

Distributed databases should not be selected merely because distribution sounds more advanced.

If you have:

20 GB database
low/moderate traffic
one region
simple application
small engineering team

a distributed database may solve problems you do not have.

And introduce problems you did not previously have.

Vertical Scaling

One way to grow is to make the server bigger.

8 CPU
  |
  v
32 CPU
  |
  v
64 CPU
  |
  v
128 CPU

Memory grows too:

32 GB
  |
  v
256 GB
  |
  v
1 TB

This is vertical scaling. It is simple and often works extremely well. Do not underestimate it.

But physical machines have limits.

Large instances become expensive.

A very large primary can also become a large failure domain.

At some point, some systems need another approach.

Replication

Instead of one server:

Primary

we can have:

              Primary
              /     \
             /       \
        Replica     Replica

Replication can provide:

• failover
• disaster recovery
• read scaling
• redundancy

But it introduces questions.

How quickly does data reach replicas?

What happens when the primary fails?

Who decides which replica becomes primary?

Can two replicas accidentally become writable?

Could an acknowledged transaction be lost?

These problems become central in distributed databases.

Horizontal Scaling

Horizontal scaling means adding machines.

Node 1
Node 2
Node 3
Node 4

But data now has to live somewhere.

Questions appear immediately.

Where does customer 1001 live?

Where does transaction 500001 live?

What happens if one query needs information from Node 1 and Node 3?

What happens when a transaction updates records stored on different nodes?

How is new hardware added?

How is data redistributed?

Horizontal scaling sounds easy until you need correct transactions.

Sharding

A traditional solution is sharding.

Example:

Customers 1 - 1M      -> MySQL 1
Customers 1M - 2M     -> MySQL 2
Customers 2M - 3M     -> MySQL 3

Or:

HASH(customer_id) % number_of_shards

The application or middleware determines where the data lives.

Sharding can work.

Many of the world’s largest systems have been built this way.

The downside is operational complexity: cross-shard transactions and queries, rebalancing, adding shards, schema changes, backups, failover, monitoring, and connection management. At 100 shards you no longer have one database. You have a fleet.

Distributed Databases and Distributed SQL

Distributed Databases

A distributed database takes responsibility for distributing data across multiple machines.

Conceptually:

                 Application
                      |
                      v
               Database Endpoint
                      |
        +-------------+-------------+
        |             |             |
      Node A        Node B        Node C
        |             |             |
      Data          Data          Data

Depending on its architecture, the database may manage:

• data placement
• replicas
• distributed transactions
• routing
• rebalancing
• failover
• leader election
• query execution

The application can interact with one logical database even though data is spread across machines.

OceanBase starts to fit into the story here.

Distributed SQL

Distributed SQL combines the relational database model with distributed architecture.

Conceptually:

SQL
+
ACID transactions
+
horizontal distribution
+
replication

Systems commonly associated with this category include:

• OceanBase
• TiDB
• CockroachDB
• YugabyteDB
• Google Spanner

These products are not architectural copies of each other.

“Distributed SQL” describes the broad problem they are trying to solve.

How they solve it differs.

The Network Problem

Once the database has several machines, the network becomes part of the database.

Node A <------X------> Node B

Both nodes are running, but they cannot communicate. Should both accept writes?

If the account balance is 50,000, Node A processes -10,000 while Node B processes -20,000. When the network returns, what is the balance?

Distributed systems need rules that prevent different parts of the system from independently creating conflicting truth.

They need consensus.

Consensus

Consensus protocols allow distributed nodes to agree on important state.

Two well-known families are:

• Paxos
• Raft

OceanBase uses Paxos-based replication.

A simplified model:

             Leader
            /      \
           /        \
     Follower      Follower

With three voting replicas:

majority = 2

If one replica fails, two remain.

A majority can still exist.

If communication leaves only one replica able to participate, a majority cannot be formed.

The system should not simply allow that isolated node to create a second independent truth.

This behavior may temporarily reduce availability, but it protects consistency.

We will test this later in OceanBase labs, on a cluster we can destroy without affecting anyone.

Where OceanBase Fits

What Is OceanBase?

We now have enough background to describe OceanBase properly.

OceanBase is a distributed relational database.

It was designed around demanding transactional workloads and large-scale distributed operation.

Its capabilities include:

• relational SQL
• distributed transactions
• horizontal scaling
• replication
• multitenancy
• transactional processing
• analytical processing
• HTAP
• MySQL compatibility
• high availability

Current versions also include vector capabilities and other search/data features.

OceanBase V4.6.0 documents further SQL, optimizer, compatibility, and execution work, including a SQL hybrid-search interface. Vector support is listed for both Community and Enterprise in the V4.4.1 feature matrix.

This means OceanBase sits across several classifications.

OceanBase
   |
   +---- Relational
   |
   +---- Distributed SQL
   |
   +---- OLTP
   |
   +---- OLAP
   |
   +---- HTAP
   |
   +---- MySQL compatible mode
   |
   +---- Vector capabilities

Calling it only an HTAP database misses most of the picture.

Read What is OceanBase? for the product-level definition, then come back here for the category map.

OceanBase Is Not MySQL With a Different Logo

MySQL engineers will recognize the SQL, drivers, and table syntax. The architecture underneath is different.

Official Community Edition documentation describes compatibility with most MySQL 5.6 and 5.7 syntax, plus some MySQL 8.0 features. Later 4.x compatibility notes describe most MySQL 5.7 or 8.0 features and statements, then list remaining differences. A compatibility matrix is not a migration plan.

The correct thinking is:

familiar interface
+
different architecture

not:

MySQL clone

That becomes very important for operations and performance.

OceanBase Architecture at a Very High Level

We will cover this properly in another article.

For now, understand a few terms.

OceanBase Cluster
      |
      +---- Zone
      |
      +---- OBServer
      |
      +---- Tenant

As we get deeper we will add:

Resource Unit
Resource Pool
Log Stream
Tablet
Replica
Partition
Paxos group

Do not try to memorize everything from one diagram.

We will learn each concept by running OceanBase and inspecting it.

That is more useful than memorizing a slide.

If you want the log-stream version now, read log stream architecture.

OceanBase for OLTP

OceanBase fits naturally into large transactional environments.

Possible examples include:

• banking
• payments
• wallets
• ecommerce
• gaming
• financial ledgers
• billing
• order processing
• large SaaS platforms

These workloads may need:

many transactions
+
consistency
+
availability
+
horizontal growth

This is one of the strongest areas in which OceanBase should be evaluated.

OceanBase for OLAP

OceanBase can run analytical SQL. The useful question is whether it is the right system for a particular analytical requirement.

If you have:

no transactional workload
petabytes of historical data
very large scans
warehouse-only use

then dedicated analytical platforms should also be evaluated.

OceanBase supporting OLAP does not mean every analytics-only database should be replaced by OceanBase.

OceanBase for HTAP

The combination is the more useful evaluation.

Payments
    |
    v
OceanBase
    |
    +---- payment transactions
    |
    +---- current fraud analysis
    |
    +---- operational reporting
    |
    +---- merchant dashboard

Reducing movement between transactional and analytical platforms can simplify some use cases and make fresher data available to analytics.

That is a legitimate reason to investigate HTAP.

It is not a reason to remove every other analytical platform from the architecture.

OceanBase and AI Workloads

Current OceanBase 4.x documentation lists vector search for both editions. Hybrid search is documented from V4.4.1, with a SQL interface in V4.6.0.

An ecommerce platform already storing:

customers
products
orders
permissions

and now needing:

product embeddings
semantic search
document retrieval

If the same database can handle suitable relational and vector workloads, architecture may become simpler.

But this should be tested.

Vector workloads have their own requirements:

• vector count
• dimensions
• recall
• index build time
• memory usage
• filtering
• latency
• query throughput

If vector search is your entire application, a dedicated vector database may still be the right answer.

Where OceanBase Fits Well

High-volume transactional systems

If the system runs substantial numbers of concurrent transactions and requires strong database guarantees, OceanBase deserves serious evaluation.

Large MySQL environments

If an organization operates increasingly large MySQL estates, OceanBase’s MySQL compatibility and distributed architecture make it relevant.

Systems approaching manual sharding

If your next architecture diagram looks like:

MySQL shard 01
MySQL shard 02
MySQL shard 03
...
MySQL shard 80

it may be time to evaluate distributed SQL.

That does not mean OceanBase automatically wins.

It means OceanBase belongs in the evaluation.

Existing sharded systems

Teams already maintaining custom routing, shard maps and cross-shard processes may gain operational benefits from moving some of that responsibility into the database layer.

Financial systems

Payments, banking, wallets and ledger workloads are a natural evaluation area for OceanBase.

HA-sensitive workloads

If database downtime immediately becomes business loss, the distributed HA architecture deserves attention.

Mixed OLTP and analytical workloads

If current operational analytics is important, OceanBase’s HTAP capability becomes relevant.

Large SaaS platforms

OceanBase’s multitenancy and resource management can be useful in consolidated database environments.

MySQL modernization

Applications wanting to retain much of the MySQL ecosystem while changing the database architecture may find OceanBase attractive.

Testing remains required.

OceanBase Migration

Another reason OceanBase becomes relevant is migration.

OceanBase Migration Assessment (OMA) can assess sources including MySQL, Oracle, PostgreSQL, TiDB, and DB2 LUW, plus several cloud MySQL-compatible platforms.

That does not mean every migration is automatic.

A migration can involve:

schema
SQL compatibility
stored procedures
data types
indexes
application behavior
drivers
performance
data movement
CDC
cutover
rollback

The professional approach is:

Current Database
      |
      v
Assessment
      |
      v
Compatibility
      |
      v
Schema Migration
      |
      v
Data Migration
      |
      v
Application Testing
      |
      v
Performance Validation
      |
      v
Cutover

We will cover this extensively later.

MySQL to OceanBase

MySQL is likely to be one of our biggest areas of focus.

Why?

Because the entry point is understandable.

An organization may have:

MySQL

and over time it grows into:

MySQL primary
replicas
shards
proxy
routing
CDC
more shards
more replicas

Eventually the organization asks:

Should we continue expanding this architecture, or move to a distributed SQL platform?

OceanBase is one answer worth evaluating.

TiDB is another.

There are others.

We should compare them honestly. Start with the MySQL migration checklist and OceanBase vs MySQL.

Oracle to OceanBase

Oracle migration is a different conversation. See OceanBase vs Oracle.

The reasons may include:

• licensing
• architecture modernization
• scaling
• vendor strategy
• cloud strategy
• operational cost

But Oracle environments can be complex.

They may include:

• PL/SQL
• packages
• procedures
• triggers
• Oracle-specific SQL
• RAC
• advanced partitioning
• proprietary features

This needs careful assessment.

Enterprise Oracle compatibility can help.

It does not remove the need for engineering.

PostgreSQL to OceanBase

PostgreSQL migrations need their own assessment because OceanBase’s main open-source compatibility path is MySQL mode rather than native PostgreSQL compatibility. See OceanBase vs PostgreSQL.

Migration tooling can help assess PostgreSQL sources, but application changes may be more significant than a MySQL-origin migration.

This is exactly why “supports migration from X” and “drop-in replacement for X” are completely different statements.

TiDB to OceanBase

TiDB and OceanBase are often compared because both operate in distributed SQL territory and have strong roots in the Asia-Pacific technology ecosystem.

But the correct comparison requires more than:

benchmark A
benchmark B

We need to compare:

• architecture
• transactions
• storage
• HTAP
• ecosystem
• operational model
• scaling
• failure behavior
• migration
• compatibility
• cost
• support

This is an area we will continue testing.

Our goal should not be:

OceanBase always wins.

Our goal should be:

Here is where each design makes sense.

That is much more useful.

Where OceanBase Does Not Fit

Where OceanBase Does Not Automatically Fit

I do not want OceanDB Pro to become a site that says:

Use OceanBase for everything.

That would not help anyone.

A 5 GB application database

If MySQL or PostgreSQL easily handles your workload, keep the simpler architecture unless you have another reason to change.

WordPress

You probably do not need a distributed database cluster to host a normal WordPress site.

A small internal application

If the application has 20 users and a modest dataset, SQLite, PostgreSQL or MySQL may be perfectly good choices.

Pure caching

If your main need is:

key
value
TTL
very low latency

Redis may be a much better fit.

Files

Store videos, images, archives and backups in object storage unless you have a very specific reason not to.

OceanBase is not S3.

Pure log search

If the primary requirement is searching massive quantities of logs, look seriously at OpenSearch, Elasticsearch, ClickHouse and similar systems.

Pure graph workloads

If your application is mainly deep relationship traversal, graph databases deserve evaluation.

Embedded applications

SQLite can be outstanding for local embedded databases.

Running OceanBase for a tiny local desktop application would make little sense.

Pure analytics

If there is no transactional requirement, a specialist analytical system may be a better choice.

A team that does not need distributed SQL

Distributed systems buy you scale and HA. They also add moving parts, failure modes, and concepts. If you do not need the benefit, you may not need the complexity.

OceanBase Community vs Enterprise

The editions share the same distributed engine for MySQL-mode work. They are not “small versus large.” They differ in specific features, compatibility modes, security capabilities, and support.

The official comparison below uses OceanBase’s V4.4.1 Community versus Enterprise matrix. Check the matrix for the version you will run.

What Community Edition Is

OceanBase Community Edition is the open-source edition, licensed under MulanPubL-2.0. Official documentation lists distributed transactions, horizontal scaling, multitenancy, high availability, HTAP, MySQL compatibility, backup and restore, and CDC among its core capabilities. Vector support is listed for Community in the V4.4.1 matrix.

It is not a demo product. This series starts here: installation, SQL, transactions, tenants, replicas, Paxos, HTAP, and the failure cases we can reproduce in a lab. You do not need Enterprise to learn how OceanBase works.

Community Edition is useful for learning, development, labs, proof of concept, migration testing, and production where its features and support model meet the requirement.

What Enterprise Edition Adds

OceanBase Enterprise is the commercial self-hosted offering. On the V4.4.1 matrix it adds Oracle syntax compatibility, auditing, advanced security scaling (row-level labels, transparent data encryption, and related controls), storage and compute separation, an independent log service, arbitration service, advanced SQL plan management, CLOG storage compression, and commercial support.

OceanBase Migration Assessment is documented as an Enterprise migration product. Community documentation notes that OMA is not included with the Community GUI tool set.

Community vs Enterprise Comparison

When Community Makes Sense

Start with Community Edition for learning, personal labs, OceanDB Pro tutorials, development, compatibility tests, technical POCs, migration testing, and architecture or performance experiments. It is also a reasonable production starting point when the organization accepts community-based support and does not need Oracle mode, auditing, TDE, or the Enterprise deployment features.

When Enterprise Makes Sense

Evaluate Enterprise when the workload needs Oracle compatibility, formal auditing, Enterprise-only security or deployment features, vendor-assisted migration with OMA, or a commercial support contract. Business-critical and regulated systems often need that last item even when Community already has the database engine features.

Support Considerations

If a core database fails, the useful question is not only which edition has a given SQL feature. It is whether someone who knows the product is contractually committed to respond. Commercial support has value even when the open-source edition can run the workload.

That does not mean every production deployment needs Enterprise. It means support belongs in the architecture decision, next to compatibility and security, not after go-live.

How to Choose a Database

Do We Need One Database or Several?

There is a popular desire to simplify architecture into one database.

Sometimes that makes sense. Sometimes it creates a worse system.

OceanBase
    |
    +---- transactions
    +---- customers
    +---- operational analytics

Redis
    |
    +---- cache

S3
    |
    +---- documents
    +---- videos

OpenSearch
    |
    +---- log search

This may be completely sensible.

The aim is not:

fewest database logos

The aim is:

reliable system
+
appropriate performance
+
reasonable cost
+
operations the team understands

Complexity should be justified.

But forced consolidation can also create complexity.

Start With Questions

Do not start with product names.

Start with questions.

What does the data look like?

Is it:

relational
documents
key-value
graph
time-series
vector
files

What is the workload?

Is it:

OLTP
OLAP
both
search
cache
AI retrieval

How much data?

1 GB?
100 GB?
10 TB?
1 PB?

How fast is it growing?

A 200 GB database growing 1 GB per month is different from one growing 500 GB per month.

What latency is required?

1 ms
10 ms
100 ms
5 seconds

These lead to different choices.

How many writes?

A read-heavy application and a write-heavy payment ledger behave differently.

What consistency is required?

A social media view counter and an account ledger have different requirements.

What happens when something fails?

Can the application be down for:

1 hour?
10 minutes?
30 seconds?
0 seconds?

Where are users located?

One region?

Several countries?

Worldwide?

What does the team know?

Operations matter. If nobody understands the database, the first serious production incident takes longer to diagnose and recover.

What does support look like?

Community, internal expertise, vendor contract, or a 24/7 SLA? That choice belongs in the architecture decision.

Database Selection Example: Small Website

Requirements:

5 GB
100 requests/second
simple CRUD
single region

Good candidates might be:

• PostgreSQL
• MySQL
• managed relational database

OceanBase?

Probably unnecessary.

You can run it.

That does not mean you should.

Database Selection Example: Payment Platform

Requirements:

very high transaction volume
strong consistency
high availability
large dataset
continued growth
SQL

Possible systems to evaluate could include:

• OceanBase
• TiDB
• distributed PostgreSQL solutions
• Oracle
• carefully engineered MySQL
• other distributed SQL databases

OceanBase?

Absolutely worth evaluating.

But still test it.

Database Selection Example: Log Analytics

Requirements:

huge ingestion
search
aggregation
retention

Candidates may include:

• ClickHouse
• OpenSearch
• Elasticsearch
• specialist observability storage

OceanBase?

Maybe for business data associated with the system.

Probably not my automatic first choice for raw log analytics.

Database Selection Example: Cache

Requirements:

temporary values
TTL
key lookup
extremely low latency

Redis becomes a natural candidate.

OceanBase?

Usually not my first choice.

The requirements do not call for its main strengths.

Database Selection Example: AI Application

Requirements:

customers
permissions
documents
embeddings
semantic search
transactions

This becomes more interesting.

You could use:

PostgreSQL + pgvector

or:

RDBMS + dedicated vector database

or potentially a system such as OceanBase that combines relational and vector capabilities.

The answer depends on scale and workload.

Benchmark it.

Where OceanBase Sits on the Database Map

Conceptually:

                       DATABASE SYSTEMS

           Relational                   Non-relational
               |                              |
      +--------+---------+          +---------+---------+
      |        |         |          |         |         |
    MySQL   PostgreSQL  Oracle    Document  Key-value Graph
      |
      |
 OceanBase
      |
      +---- Distributed SQL
      |
      +---- OLTP
      |
      +---- OLAP
      |
      +---- HTAP
      |
      +---- Vector/search capabilities

This is why one-word descriptions of OceanBase are incomplete.

A Database Selection Decision Tree

Start here:

Do you need persistent structured business data?
                    |
                   Yes
                    |
           Do relationships matter?
              /              \
            Yes               No
             |                 |
       Consider RDBMS      Consider other
             |             data models
             |
       Mostly OLTP?
         /       \
       Yes       No
        |         |
  Can one DB     Mostly analytics?
  server handle   |
  the workload?   +----> Evaluate OLAP platforms
     /    \
   Yes    No
    |      |
MySQL/   Need horizontal scale,
PG may   HA and distributed SQL?
be fine      |
            Yes
             |
      Evaluate distributed SQL
             |
      OceanBase becomes
      one candidate

Then:

Need significant analytics
on current transactional data?
            |
           Yes
            |
         HTAP matters
            |
      OceanBase becomes
      more interesting

This is the right order.

Problem first.

Technology second.

Categories Overlap. That Is the Point.

Database categories overlap.

That one fact clears up much of the confusion.

OLTP is not the opposite of relational.

OLAP is not synonymous with column store.

NoSQL is not synonymous with unstructured data.

In-memory does not automatically mean cache.

Vector does not automatically mean AI-only.

Distributed does not automatically mean HTAP.

HTAP does not mean warehouse replacement.

OceanBase can simultaneously be:

relational
distributed
OLTP
OLAP-capable
HTAP
MySQL-compatible
vector-capable

because those words describe different aspects of the system.

Quick Database Reference

So, Should You Use OceanBase?

Start evaluating OceanBase seriously when you recognize problems such as:

Our MySQL architecture keeps growing.

We are adding more shards.

Database HA is becoming complicated.

Our dataset is becoming very large.

We need horizontal scaling.

We run high-volume transactions.

We need strong consistency.

We need operational analytics close to transactional data.

We are evaluating distributed SQL.

We want to modernize a large MySQL environment.

We are looking at Oracle modernization.

We need a database that can combine several workload types.

These are real reasons.

Do not use OceanBase merely because:

It is distributed.

It sounds advanced.

It has good benchmark numbers.

Everyone is talking about AI databases.

You want HTAP on an architecture diagram.

Technology should solve a problem. Otherwise it eventually becomes the problem.

Where We Go Next

What a MySQL DBA Already Knows

If you already understand MySQL, a lot of your knowledge carries over.

You know:

• schemas
• tables
• indexes
• SQL
• joins
• transactions
• execution plans
• backups
• users
• privileges
• replication concepts
• performance tuning

OceanBase then adds another layer.

You need to understand:

Cluster
Zone
OBServer
Tenant
Resource Unit
Resource Pool
Log Stream
Tablet
Replica
Paxos
Distributed transactions
Distributed SQL execution

So OceanBase can initially feel familiar.

Then suddenly very unfamiliar.

That is normal.

Why We Are Starting With Docker

Our first practical OceanBase exercise will use Docker.

Not because Docker represents the architecture we would automatically recommend for a production financial platform.

It does not.

We use Docker because it gives us a simple environment in which to:

install
connect
query
break
restart
inspect

without spending the first day building production infrastructure.

We want to learn the database first.

Our First OceanBase Application

Instead of creating:

CREATE TABLE test (
    id INT
);

we are going to build a small payment database.

Tables will include:

customers
accounts
transactions

Eventually we can add:

merchants
payments
ledger_entries
devices

This gives us one evolving dataset for the entire learning series.

We can use it to test:

• ACID transactions
• indexes
• isolation
• partitioning
• data distribution
• HTAP
• analytics
• high availability
• distributed transactions
• backup
• migration
• vector features

That is much more useful than disconnected tutorial tables.

What We Will Test

I do not want this series to become rewritten documentation.

For each topic, we should ask:

What does OceanBase claim?

How do I test it?

What happened?

What broke?

What surprised me?

We will test:

• Docker installation
• MySQL connectivity
• transactions
• rollback
• tenants
• resource management
• storage
• partitions
• query plans
• replicas
• leader failure
• quorum loss
• HTAP
• row vs column behavior
• backup
• recovery
• MySQL migration
• vector search

When something fails, we include the failure.

Real troubleshooting is more useful than a tutorial where every command magically works.

What We Will Not Do

We will not write:

OceanBase is the perfect database for every modern application.

It is not.

We will not publish:

OceanBase is 10x faster than X.

unless we have a reproducible test that supports the statement and explains the environment.

We will not assume:

MySQL compatible means zero migration work.

It does not.

We will not say:

HTAP eliminates data warehouses.

It does not universally.

We will not claim:

Open source means production support requirements do not matter.

They do.

This site should help people make database decisions, not simply convince them to choose OceanBase.

What Comes Next

The next step is not another theory article. We are going to install it.

Our next guide will be:

Installing OceanBase Community Edition With Docker: From Zero to First Transaction

We will:

Install Docker
      |
      v
Start OceanBase Community Edition
      |
      v
Watch startup
      |
      v
Connect using obclient
      |
      v
Check the OceanBase version
      |
      v
Inspect the environment
      |
      v
Create our payment database
      |
      v
Create customers
      |
      v
Create accounts
      |
      v
Create transactions
      |
      v
Run COMMIT
      |
      v
Run ROLLBACK
      |
      v
Restart OceanBase
      |
      v
Verify our data

After that we start opening the database up: what a tenant is, what an OBServer does, where data lives, how resources are assigned, how OceanBase stores and replicates information, what happens when a node dies, how Paxos behaves in the running system, how HTAP looks in practice, and how a MySQL migration actually goes.

That is where we will see where OceanBase performs well, and where it does not. The real series starts there.