High availability is often associated with replication: one database node sends changes to another, and the standby takes over when the primary fails.
But replication introduces a fundamental question:
What happens to transactions that have been committed locally but have not yet reached the standby?
This is where shared-storage architecture takes a different approach.
How Shared-Storage HA Works
GBase Database (GBase 8s) uses a shared-storage architecture in which multiple database nodes can access the same underlying data storage.
Instead of maintaining independent data copies on each database node, compute nodes share access to the storage layer.
This changes the failure model.
With replication-based HA, failover may require the standby to catch up with the latest changes. With shared storage, the surviving node can access the same persistent data after a failure.
The goal is to eliminate data loss caused by replication lag.
RPO=0: What Does It Really Mean?
An RPO of 0 means that committed transactions should not be lost after a recoverable failure.
Shared storage can support this model because the database nodes are working against the same persistent data rather than waiting for transaction changes to be replicated to another data copy.
However, RPO=0 should never be treated as a property of shared storage alone.
The storage layer, database configuration, failure detection, and recovery design all need to work together. Storage protection is therefore a critical part of the overall HA architecture.
What About RTO?
The recovery process is also different from traditional replication-based failover.
There is no need to move or synchronize an entire data copy before the surviving database node can take over. Instead, the recovery process focuses on node ownership, transaction state, and service availability.
For appropriately designed deployments, GBase Database (GBase 8s) targets rapid recovery, with RTO requirements potentially reaching the seconds range depending on the deployment architecture and environment.
The Trade-Offs
Shared storage is not a free solution.
The storage infrastructure becomes a critical component and must itself be highly available and protected. Large-scale deployments may therefore use redundant storage, multiple sites, or multi-center architectures.
There can also be architectural constraints around the shared storage fabric, particularly for write-intensive workloads.
So the real comparison is not:
Replication vs. shared storage — which is better?
It is:
Which failure model matches the business requirement?
For systems such as core financial ledgers, where losing a committed transaction is unacceptable, an architecture designed around shared persistent storage can provide a compelling HA model.
The Bigger Lesson
RPO=0 is not a checkbox on a database feature list.
It is an architectural outcome.
For GBase Database, understanding how the database, shared storage, failure detection, recovery process, and infrastructure protection work together is more important than looking at an RPO number in isolation.
When evaluating high availability, ask three questions:
- Where does the committed transaction physically reside?
- What happens when the active database node fails?
- How does the system recover without losing committed data?
Those answers tell you far more about HA than an availability percentage alone.
