Design the storage path around every committed transaction
Database performance depends on more than headline throughput. Predictable write latency, correct flush behaviour, stable storage, recovery points and a tested failover path determine whether a transactional service remains both fast and trustworthy.
One database produces several storage workloads
Sizing only for capacity or aggregate bandwidth overlooks the operations that govern transaction time and recovery behaviour.
Frequent durability points
Write-ahead and redo logs commonly issue small sequential writes whose completion can sit directly in the transaction path.
Mixed, concurrent access
Reads, page updates, background flushing and index maintenance compete for queues and cache resources.
Bursts from sorts and joins
Temporary data, spills and maintenance tasks can create short periods of high throughput and queue depth.
Background work becomes visible
Dirty-page flushing, snapshots, rebuilds or backup activity can change latency even when the application workload has not changed.
Important: a database benchmark should reproduce transaction mix, concurrency, working set, protection policy and failure-state operation. A short sequential test does not represent this behaviour.
Protect correctness before optimising speed
Stable writes
Flushes, write ordering and protected caches must preserve the durability model expected by the database and operating system.
Predictable latency
Review normal operation, peak periods, degraded mode, rebuilds, snapshots and backup windows—not only the fastest result.
Path resilience
Multipathing, redundant network links and correctly configured host time-outs reduce the chance that one path event stops the service.
Recoverable history
Application-consistent backup, retained recovery points and restore testing remain necessary even when storage is highly available.
Different database services stress different parts of the system
The application owner and storage designer should describe the workload before selecting a transport or platform.
Online transaction processing
Latency-led
- Many concurrent, relatively small operations
- Commit latency and tail latency can affect user response time
- Logs and data may need different service levels
Analytics and reporting
Throughput-led
- Large scans and parallel reads can consume bandwidth
- Temporary work areas may create bursty writes
- Capacity growth and data movement matter alongside latency
Consolidated database VMs
Mixed demand
- Several databases share host, fabric and storage queues
- Noisy neighbours can make latency less predictable
- Virtualisation HA and storage HA solve different failure layers
Distributed and scale-out data services
Failure-domain led
- The application and storage may both replicate data
- Placement policy changes capacity and write amplification
- Quorum, recovery traffic and degraded mode require testing
Block, file and object storage serve different database roles
Block storage
The host receives a volume and the operating system controls its filesystem. This is the conventional choice for many transactional databases and clustered database designs.
Common roles
- Data and index volumes
- Transaction or redo logs
- Database volumes inside virtual machines
File storage
The database accesses files through a shared filesystem protocol. Suitability depends on the database vendor, operating system, locking semantics and the supported deployment design.
Common roles
- Supported database shares
- Exports, imports and shared content
- Backup repositories
Object storage
Applications address objects through an API rather than a mounted database volume. It is normally a complementary tier, not a direct replacement for transactional block I/O.
Common roles
- Database backup and archive
- Data-lake and analytics content
- Application objects and unstructured data
Do not select by protocol name alone: confirm that the database, operating system, clustering method and backup tooling support the complete configuration.
Choose the fabric by operational fit and latency objective
Every shared-storage protocol can be implemented well or poorly. The complete path and supported host configuration determine the result.
| Access method | Infrastructure | Performance character | Operational advantage | Points to validate |
|---|---|---|---|---|
| Local NVMe | PCIe-attached media in the database host | Very low local latency | Short I/O path and no storage fabric | Host failure boundaries, shared access, migration and external recovery |
| NVMe over RDMA | RoCE/RoCEv2 or InfiniBand fabric | Low overhead and low latency potential | Extends NVMe block access across a fabric | Qualified adapters, switches, fabric configuration, multipathing and operations skills |
| NVMe over TCP | Standard routed Ethernet/IP network | Efficient NVMe access over TCP | Familiar IP operations and broad network reach | CPU load, congestion, path design, host support and workload latency |
| Fibre Channel | Dedicated FC fabric with HBAs and switches | Mature and predictable when correctly designed | Established SAN isolation, zoning and multipath practices | Specialist infrastructure, port capacity, interoperability and lifecycle cost |
| iSCSI | Ethernet/IP network and standard SCSI initiators | Mature general-purpose block access | Broad compatibility and familiar administration | Network separation, queueing, multipathing, time-outs and peak workload behaviour |
| File protocol | Shared file service over Ethernet | Depends strongly on client and workload | File-level administration and shared namespaces | Explicit database support, locking, cache semantics and application design |
NVMe over TCP and NVMe over RDMA use the NVMe over Fabrics architecture but make different infrastructure trade-offs. RDMA can reduce transport overhead; TCP usually fits more easily into established IP operations. Measure with the intended database workload.
Separate I/O classes logically—even when they share hardware
Logs, data, temporary work and backups do not always need separate storage systems. They do need identifiable policies, capacity limits and monitoring so that one activity does not unexpectedly consume the service level required by another.
- Protect the transaction-log path from uncontrolled queueing.
- Allow space for checkpoints, maintenance and rebuild traffic.
- Keep backup traffic from dominating the production path.
- Monitor latency percentiles and saturation, not only bandwidth.
Four I/O lanes, four operating questions
Isolation may use volumes, namespaces, pools, quality-of-service controls or separate paths according to the platform.
Match the platform to the database failure boundary
These euroNAS examples illustrate different implementation models. They are not a substitute for validating the database vendor’s supported configuration.
Dedicated high-performance storage
Standalone
A focused storage system for database environments whose availability design is handled at the host, application or recovery layer. It can also be deployed as a Virtual Storage Appliance where that architecture is appropriate.
- Block access using the protocol selected for the hosts
- Snapshots and scheduled replication for storage recovery points
- No automatic storage-controller failover within one standalone server
Two-node database storage availability
Automatic failover
A two-node storage design with automatic service failover, implemented as a synchronous Mirror between servers or with dual controllers and shared storage.
- Designed for local storage-service continuity
- Multipathing protects host access across available paths
- Snapshots and scheduled replication remain separate recovery controls
Distributed scale-out database storage
No fixed two-node limit
Distributed block storage across multiple nodes can suit capacity growth, infrastructure fault tolerance and larger consolidated environments.
- Protection across defined Ceph failure domains
- Scale capacity and performance by adding qualified nodes
- Validate latency, recovery traffic and application-level replication together
Databases as protected virtual machines
Virtualisation platform
eEVOS runs database workloads as virtual machines and can use mirrored, shared or Ceph storage according to the cluster design. External shared storage can also be connected.
- Virtual-machine HA and live migration
- Internal or external storage options
- Integrated Backup & Disaster Recovery, including Instant Backup & Recovery
Protect the service at more than one layer
Database clustering, storage failover, replication and backup are complementary controls with different recovery outcomes.
Keep access available
Redundant links and multipathing protect against an adapter, cable, switch port or storage path failure.
Continue after a node fails
Application clustering, virtualisation HA or storage failover can restart or continue the service at different layers.
Cross a larger boundary
Synchronous and asynchronous copies address different distance, data-loss and performance objectives.
Return to a usable state
Retained recovery points and tested procedures protect against deletion, corruption, security incidents and site loss.
Application consistency matters: coordinate database flushes, snapshots, replication and backup with the database’s supported recovery model. A storage-consistent copy is not automatically an application-consistent recovery point.
euroNAS platforms address different database designs
Selection should follow workload, host support, failure boundaries and operational skills—not a single protocol or feature.
| Platform | Primary database role | Storage model | Availability contribution | Design consideration |
|---|---|---|---|---|
| euroNAS Premium | Dedicated or virtual storage appliance for a focused database environment | Standalone block and file storage | Host multipathing where configured, plus storage recovery points | Application or external recovery design must cover complete server loss |
| euroNAS HA Cluster | Shared database storage requiring automatic local storage failover | Two-node synchronous Mirror or dual-controller shared storage | Automatic storage-service failover and multipathed host access | Size performance for normal and failover operation; retain separate backups |
| eEKAS | Distributed block storage for larger consolidated or scale-out environments | Ceph across multiple storage nodes and failure domains | Distributed redundancy, recovery and scale without a fixed two-node boundary | Test database latency together with Ceph protection and degraded-mode recovery |
| eEVOS | Database virtual machines on an integrated virtualisation platform | Mirrored, external shared or Ceph storage according to deployment | VM HA, live migration and storage architecture chosen for the cluster | Coordinate database-native protection with integrated VM Backup & Disaster Recovery |
euroNAS Premium
Standalone storage for database hosts or virtualised environments.
HA Cluster
Automatic two-node storage failover with a synchronous Mirror or shared-storage design, plus scheduled asynchronous replication for additional recovery protection.
eEKAS
Ceph block storage across nodes and defined failure domains.
eEVOS
Virtualisation, storage and VM Backup & Disaster Recovery in one platform.
Ask questions the benchmark cannot answer
What are the read/write mix, concurrency, block sizes, log behaviour and latency objectives?
What performance remains acceptable during path loss, failover, rebuild or distributed recovery?
Which flush, cache-protection, write-ordering and stable-media guarantees does the database require?
Which operating systems, multipath drivers, hypervisors and database cluster modes are qualified?
Which RPO and RTO apply to deletion, corruption, node loss and a complete site outage?
Will capacity, transaction rate, node count or retention grow—and which component reaches its limit first?
Independent technical guidance
Database and transport requirements evolve. Validate the final design against the current database, operating-system and storage documentation.
NVM Express: NVMe over RDMA
Official overview of the RDMA transport and its low-overhead memory-to-memory data path.
PostgreSQL: Write-Ahead Logging
How WAL supports data integrity and recovery by persisting log records before changed data pages.
Microsoft: SQL Server I/O requirements
Write ordering, stable media, dependent-write consistency and torn-I/O considerations.
MySQL: InnoDB redo log
The role of redo logging in crash recovery and the relationship between log capacity and background flushing.
Bring the database workload—not only the capacity figure
We can review transaction characteristics, latency objectives, host compatibility, availability, recovery and growth for a business database or virtualisation design.