When database teams discuss distributed architecture, one question often comes up:
Is Shared-Nothing more scalable than Shared Storage?
The short answer is: it depends on the workload.
Shared Storage and Shared-Nothing solve different architectural problems. One emphasizes shared data access, centralized consistency, and simplified failover. The other emphasizes horizontal scalability, distributed storage, and parallel data processing.
The GBase Database product family uses both approaches rather than forcing every workload into a single architecture:
GBase Database(GBase 8s) uses a shared-storage cluster architecture for enterprise transactional workloads.
GBase Database(GBase 8a MPP Cluster) uses a Shared-Nothing MPP architecture for large-scale analytical workloads.
Understanding why these architectures are different is more useful than simply asking which one is "better."
1. GBase Database(GBase 8s): Shared Storage
A Shared Storage architecture allows multiple database nodes to access the same underlying data.
A simplified model looks like this:
┌─────────────┐ ┌─────────────┐
│ Node 1 │ │ Node 2 │
│ Active │ │ Standby │
└──────┬──────┘ └──────┬──────┘
│ │
└─────────┬──────────┘
│
┌────────┴────────┐
│ Shared Storage │
│ SAN / NAS │
└─────────────────┘
The key characteristic is simple:
The database nodes share the same data storage.
This has an important consequence for high-availability design.
When a database node fails, the standby node does not necessarily need to rebuild an independent copy of the entire dataset before taking over. Because the underlying data is already shared, recovery can focus on service and state transition rather than full data redistribution.
For enterprise OLTP systems, this can simplify the HA architecture considerably.
Why Shared Storage works well for OLTP
Transactional systems often prioritize:
Strong consistency
Predictable transaction latency
High concurrency
Fast failover
Centralized data access
Operational simplicity
These characteristics make Shared Storage a useful architectural choice for workloads where data consistency and availability are more important than unlimited horizontal scaling.
GBase Database(GBase 8s) is designed around this model for enterprise transactional workloads.
A production deployment in a metro system has been reported at approximately 30,000 concurrent connections and 1.6 million TPMC under its specific workload and infrastructure conditions.
The important architectural point is not the benchmark number itself.
It is that Shared Storage can provide a practical foundation for large-scale transactional systems without requiring every node to maintain an independent copy of the dataset.
2. The Trade-Off: Shared Storage Has a Scaling Boundary
Shared Storage does not mean infinite scalability.
As database nodes increase, the shared storage subsystem can become an important part of the overall performance equation.
Consider:
More database nodes
↓
More concurrent I/O
↓
Higher storage bandwidth requirements
↓
Shared storage becomes a potential bottleneck
The scaling boundary therefore depends on the capacity of the storage subsystem, network, controllers, and database workload.
This does not make Shared Storage "bad."
It simply means that the architecture has a different scaling model from Shared-Nothing.
For workloads dominated by transactional operations, that trade-off can be worthwhile because the system gains a simpler shared-data model and predictable access to the same dataset.
3. GBase Database(GBase 8a): Shared-Nothing MPP
The architecture is fundamentally different in GBase Database(GBase 8a MPP Cluster).
Instead of multiple database nodes accessing the same storage, each node owns its own local data and compute resources.
A simplified model looks like this:
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Node 1 │ │ Node 2 │ │ Node 3 │
│ Data 1 │ │ Data 2 │ │ Data 3 │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└──────────────┼──────────────┘
│
┌─────┴─────┐
│ Network │
└───────────┘
This is the classic Shared-Nothing principle:
Each node owns its own storage and compute resources.
As additional nodes are added, both storage capacity and processing capacity can increase.
This makes Shared-Nothing particularly attractive for analytical workloads where large datasets can be partitioned across many nodes and processed in parallel.
4. Why Shared-Nothing Works Well for OLAP
Consider an analytical query scanning billions of rows:
SELECT
region,
product_category,
SUM(revenue) AS total_revenue
FROM sales_fact
WHERE year >= 2025
GROUP BY region, product_category;
With an MPP architecture, different nodes can process different portions of the dataset simultaneously.
Conceptually:
SQL Query
│
┌─────────┴─────────┐
↓ ↓ ↓
Node 1 Node 2 Node 3
Scan Scan Scan
│ │ │
└─────────┼─────────┘
↓
Aggregate
↓
Result
The architecture can therefore scale by distributing both data and computation.
GBase Database(GBase 8a) is designed for this type of workload, with columnar processing, MPP execution, and distributed storage.
The product has been positioned for large-scale analytical workloads, with reported configurations reaching thousands of nodes and high-volume data processing.
But horizontal scaling introduces another trade-off.
5. The Cost of Distribution: Network Overhead
Distributed processing is not free.
Suppose a query needs to join two tables whose relevant data resides on different nodes.
The system may need to exchange data across the network before completing the join.
Conceptually:
Node 1 Node 2
Table A Table B
│ │
└────── Network ─────┘
│
JOIN
This network movement can become expensive for poorly distributed workloads.
Therefore, good MPP database design pays close attention to:
Data distribution keys
Partitioning
Join strategies
Data locality
Network bandwidth
Parallel execution
This is one reason why Shared-Nothing is not automatically better than Shared Storage.
It provides a different scaling model, with different optimization requirements.
6. Shared Storage vs Shared-Nothing
| Factor | GBase Database(GBase 8s) | GBase Database(GBase 8a) |
|---|---|---|
| Architecture | Shared Storage | Shared-Nothing MPP |
| Data model | Shared data access | Distributed data |
| Scaling model | Primarily infrastructure/storage constrained | Horizontal scale-out |
| Main strength | Transaction processing and HA | Parallel analytical processing |
| Typical workload | OLTP | OLAP |
| Key optimization | Transactions, indexes, concurrency | Distribution, parallelism, data locality |
| Main trade-off | Shared storage can become a scaling boundary | Cross-node data movement adds network cost |
The important difference is therefore not simply:
Shared Storage = old
Shared-Nothing = new
That is an overly simplistic way to evaluate database architecture.
A better model is:
Architecture → Workload → Bottleneck → Scaling requirement
7. Which Architecture Should You Choose?
Choose Shared Storage when:
Your workload requires:
High-concurrency OLTP
Strong transactional consistency
Predictable transaction latency
High availability
Shared access to the same dataset
Fast and simplified failover
This is where GBase Database(GBase 8s) fits naturally.
Choose Shared-Nothing when:
Your workload requires:
Large-scale analytical processing
Distributed storage
Massive parallel execution
Horizontal scale-out
Large data scans
Data warehouse or BI workloads
This is where GBase Database(GBase 8a MPP Cluster) becomes a more natural fit.
8. The Real Question Is Not "Which Is More Advanced?"
Database architecture discussions often become technology debates.
Shared Storage is described as centralized.
Shared-Nothing is described as distributed.
But neither label tells you whether the architecture is appropriate for a specific application.
A better evaluation starts with the workload:
Is the workload transaction-heavy?
│
├── Yes → Evaluate Shared Storage
│
└── No
│
↓
Is it dominated by large-scale analytics?
│
├── Yes → Evaluate Shared-Nothing MPP
│
└── No → Consider a mixed/HTAP architecture
For GBase Database, the use of both architectures reflects this workload-first philosophy.
GBase Database(GBase 8s) does not need to behave like an MPP analytical database.
GBase Database(GBase 8a MPP Cluster) does not need to behave like a centralized OLTP database.
They solve different problems.
Conclusion
Shared Storage and Shared-Nothing represent different approaches to distributing database resources.
GBase Database(GBase 8s) uses Shared Storage to prioritize enterprise transaction processing, shared data access, and high availability.
GBase Database(GBase 8a MPP Cluster) uses Shared-Nothing to prioritize distributed storage, parallel processing, and horizontal scalability for analytical workloads.
The architectural lesson is straightforward:
Don't choose a database architecture because one architecture sounds more modern. Choose it because its scaling model matches your workload.
For GBase Database, having different architectural approaches across product lines is not a contradiction. It is a recognition that OLTP and OLAP have fundamentally different performance and scaling requirements.
Top comments (0)