Shared Storage vs Shared-Nothing: How GBase Database Uses Two Architectures

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

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.