Choosing a database isn't just about comparing feature lists.
The first question should be:
What does your workload actually look like?
GBase Database is not a single architecture designed for every workload. Its product family covers different workload patterns across OLTP, HTAP, and OLAP.
This FAQ walks through nine practical questions to help you narrow down the right GBase Database direction.
Q1: Who Should Use GBase Database?
Teams that can clearly describe their workload.
Before choosing GBase Database, classify your system first:
- Transaction-heavy → OLTP
- Analysis-heavy → OLAP
- Mixed transactional + analytical → HTAP
The goal isn't to find the "most advanced" database.
It's to find the architecture that matches your workload.
Q2: Is GBase Database One Database or a Family?
It's a database family.
The three major product directions are:
| Workload | GBase Database Direction | Architecture |
|---|---|---|
| OLTP | GBase Database(GBase 8s) | Centralized / shared-storage |
| HTAP | GBase Database(GBase 8c) | Distributed / multi-engine |
| OLAP | GBase Database(GBase 8a) | Columnar MPP |
This distinction is important.
GBase Database(GBase 8s) isn't simply a smaller or older version of GBase Database(GBase 8c).
GBase Database(GBase 8c) isn't intended to replace every analytical workload.
And GBase Database(GBase 8a) isn't designed to become an OLTP database.
Each product direction exists because the workload requirements are different.
Q3: Which GBase Database Is Best for Transaction-Heavy Workloads?
For enterprise OLTP workloads, look at GBase Database(GBase 8s).
Its architecture focuses on centralized transaction processing with shared-storage high availability.
This makes it particularly relevant for workloads where you need:
- High transaction concurrency
- Strong consistency
- Predictable latency
- Enterprise high availability
- Oracle-oriented compatibility
- Mission-critical transactional processing
For example, Shenzhen Metro's ACC system has been cited as running with around 30,000 concurrent users.
The important point isn't simply the concurrency number.
It's that the architecture is designed around transaction-heavy operational workloads.
Q4: Which GBase Database Is Best for Analysis-Heavy Workloads?
For large-scale analytical workloads, look at GBase Database(GBase 8a) and its MPP architecture.
The focus is different from OLTP:
- Columnar storage
- Parallel query execution
- Large-scale scans
- Complex aggregation
- Data warehouse workloads
- Large analytical datasets
GBase Database(GBase 8a) also uses columnar compression, with reported compression ratios in the 1:20–1:30 range depending on workload and data characteristics.
For PB-scale analytical environments and large ad-hoc queries, horizontal MPP processing can be a better architectural fit than trying to extend a transactional database beyond its intended workload.
Q5: Which GBase Database Is Best for Mixed Workloads?
When transactions and analytics need to coexist around the same operational data, evaluate GBase Database(GBase 8c).
Its architecture combines multiple processing approaches, including:
- Row-oriented processing
- Column-oriented processing
- In-memory processing
The goal is to support workloads where the same data needs to serve both operational transactions and analytical queries.
Think about a financial system that needs to process transactions throughout the day while simultaneously running risk analysis, operational dashboards, or other analytical workloads.
You could build:
OLTP
↓
CDC / ETL
↓
OLAP
But if data freshness, pipeline complexity, and operational overhead become significant concerns, an HTAP architecture may be worth evaluating.
That's the workload zone GBase Database(GBase 8c) is designed to address.
Q6: How Should I Judge Data Scale?
Don't use data volume as the only architecture decision.
A better question is:
How much data does each query need to process, and how fast is that workload growing?
For example:
A 50 TB database dominated by indexed point lookups may still be fundamentally OLTP.
A 10 TB database with constant large scans and complex aggregations may already have strong analytical characteristics.
As data volume and growth accelerate, horizontal scaling and MPP architectures become increasingly important.
So instead of:
"We have X TB, which database should we buy?"
Ask:
"What is the relationship between data volume, query pattern, concurrency, and growth rate?"
That gives you a much better architecture decision.
Q7: Can I Choose a GBase Database Based on My Current Database?
Your current database is a useful starting point—but it shouldn't be the final decision criterion.
A practical migration mapping might look like this:
| Source Environment | Initial GBase Database Direction | Why |
|---|---|---|
| Oracle, transaction-heavy | GBase Database(GBase 8s) | OLTP + Oracle-oriented compatibility |
| MySQL / PostgreSQL, mixed workloads | GBase Database(GBase 8c) | Distributed mixed workload direction |
| ClickHouse / Greenplum-class analytics | GBase Database(GBase 8a) | Columnar MPP analytics |
But this is only a starting hypothesis.
A migration from Oracle doesn't automatically mean GBase Database(GBase 8s).
Likewise, migrating from PostgreSQL doesn't automatically mean GBase Database(GBase 8c).
The correct process is:
Source database → workload analysis → compatibility assessment → architecture selection → POC
The workload should have the final say.
Q8: Are There Real Production Cases?
Yes.
Production validation is one of the most important things to investigate when evaluating GBase Database.
Examples cited in GBase Database case studies include:
Shenzhen Metro ACC
A production deployment reported at around 30,000 concurrent users, demonstrating the use of GBase Database in a large-scale transactional environment.
Sinotruk
An analytical workload reportedly improved from more than 10 seconds to sub-second response time after optimization and migration.
Huatai Securities
A system that previously encountered stability issues at around 2,000 devices was reported to operate stably at around 4,000 devices after the deployment was optimized.
These numbers should not be treated as universal performance guarantees.
The more useful lesson is:
Ask whether the vendor has production cases that resemble your workload.
Your POC should reproduce your own workload—not simply copy somebody else's benchmark.
Q9: How Do I Verify Whether GBase Database Fits My Environment?
Don't make the final decision from a product brochure.
Build a workload baseline first.
Step 1: Quantify the workload
If you're working in a PostgreSQL-compatible environment with pg_stat_statements, you can start with a simple transaction/query split:
SELECT
SUM(
CASE
WHEN command IN ('INSERT', 'UPDATE', 'DELETE')
THEN 1
ELSE 0
END
) AS tp_ops,
SUM(
CASE
WHEN command = 'SELECT'
THEN 1
ELSE 0
END
) AS ap_ops
FROM pg_stat_statements;
This is only a first-level indicator.
A SELECT could be a single-row lookup—or a multi-billion-row aggregation.
So don't stop here.
Step 2: Build a SQL baseline
Collect your actual production workload:
- Top CPU-consuming SQL
- Top I/O-consuming SQL
- Slow SQL
- High-frequency SQL
- Stored procedures
- Triggers
- Views
- Application-generated SQL
The goal is to test your workload, not a vendor-created benchmark.
Step 3: Compare execution plans
For representative SQL, compare:
Source Database
↓
Execution Plan
↓
GBase Database
↓
Execution Plan
Look for differences in:
- Index usage
- Join strategy
- Cardinality estimates
- Scan method
- Sort operations
- Aggregation strategy
- Parallel execution
Step 4: Test concurrency
A query that performs well with one user may behave very differently with 1,000 concurrent users.
Test:
- Average latency
- P95 / P99 latency
- Throughput
- CPU utilization
- I/O
- Lock contention
- Connection behavior
Step 5: Test the migration toolchain
Migration isn't finished when the schema is converted.
Evaluate the complete workflow:
Assessment → Schema conversion → Data migration → Synchronization → Validation → Cutover → Rollback
For GBase Database, this means evaluating the relevant migration and synchronization tools alongside the database itself.
Step 6: Test backup and recovery
Finally, test what happens when things go wrong.
Don't only test:
"Can we migrate successfully?"
Also test:
"Can we recover successfully?"
Validate:
- Backup
- Restore
- Point-in-time recovery where applicable
- Failover
- Disaster recovery
- Rollback
- Data consistency
The Simple Decision Tree
If you need a quick starting point:
Start
│
▼
What is the workload?
│
┌───────────┼───────────┐
▼ ▼ ▼
OLTP HTAP OLAP
│ │ │
▼ ▼ ▼
GBase Database GBase Database GBase Database
(GBase 8s) (GBase 8c) (GBase 8a)
│ │ │
▼ ▼ ▼
Transactions Mixed loads Analytics
High concurrency Shared data Large scans
Low latency Low latency MPP
This isn't a replacement for a POC.
It's simply a way to avoid choosing an architecture before understanding the workload.
The Bottom Line
Choosing a GBase Database isn't really a product-selection problem.
It's a workload-classification problem.
Start with three questions:
1. Is the workload primarily transactional, analytical, or mixed?
2. What does the real production SQL look like?
3. Can the target architecture meet the workload, migration, and operational requirements?
Then map the result to the appropriate GBase Database direction:
OLTP → GBase Database(GBase 8s)
HTAP → GBase Database(GBase 8c)
OLAP → GBase Database(GBase 8a)
The best database isn't the one with the longest feature list.
It's the one whose architecture matches your workload—and whose migration and operations model you can actually support.
Classify first. POC second. Choose last.
Top comments (0)