Should you choose NVMe or SAS for an accounting system?

For an accounting system used by 100 people, I would choose enterprise NVMe drives by default, but not because their sequential read figures look better. Low latency for short random operations at a shallow queue depth matters more. Those are the operations between a click on “Post” and the result appearing on an accountant's screen. A sound SAS SSD array can also deliver fast, predictable response times. An array of SAS hard drives will almost always lose when a hundred people work concurrently, even when it has enough capacity and headline throughput.

The user count proves nothing by itself. One hundred cashiers entering short documents, one hundred analysts running heavy reports, and forty active employees out of a hundred registered accounts create different loads. Before buying anything, measure the current database latency, read and write mix, active data size, period-close peaks, and transaction log behavior. The choice then often becomes straightforward: use NVMe where storage already delays queries; SAS remains sensible when compatibility, dual-port access, or reuse of a sound enterprise enclosure matters more.

One hundred users do not equal one hundred concurrent requests

You cannot size storage from the account count because storage sees I/O operations, not people. One user may open a form and read it for ten minutes without touching the disk. Another starts a document reposting job that reads indexes, changes many rows, writes the log, and creates temporary data. A formula that assigns a fixed number of IOPS to every user makes a quotation easier to prepare, but it has little technical meaning.

First, separate registered users from active ones. Then find the heaviest normal interval: the morning data exchange, a bulk bank import, payroll, day or month close, or a statutory report. A daily average will hide the exact period that makes employees call the system slow.

Four groups of database metrics are useful:

• read and write latency for data files, the log, and the temporary database;
• physical reads, writes, and bytes transferred per second;
• queue length and the 95th or 99th percentile response time;
• database waits, CPU load, available memory, and blocking.

The last group prevents you from buying expensive drives to fix a query. Microsoft's SQL Server troubleshooting guidance explicitly separates storage latency, excessive logical reads, memory pressure, blocking, and filter-driver overhead. If a query reads millions of rows because an index is missing, NVMe will shorten the physical wait but will not turn a bad execution plan into a good one. If all working pages are already in the buffer cache, replacing SAS SSDs with NVMe may barely change how fast an ordinary form opens.

An accounting system needs both averages and peak behavior. Record how many sessions are active in a normal hour and at the peak, which operations slow down, and how long the delay feels to the user. Those observations connect server metrics to the actual complaint. Without that connection, it is easy to optimize a test for an abstract record.

The active data set often matters more than the total database size. Seven years of archives may occupy several terabytes while a normal day touches reference tables, recent documents, and a limited set of indexes. When the active portion fits in memory, drives handle cache misses, writes, and background work. When memory is tight, the database keeps evicting and rereading pages, so storage traffic rises sharply. Before replacing drives, check whether another virtual machine has taken the memory and whether the database engine's maximum memory setting is too low.

Virtualization adds another measurement layer. A guest can show a queue on its virtual disk while the delay actually occurs in a shared datastore, an HBA, or a neighboring virtual machine. Capture metrics inside the guest and at the hypervisor over the same interval. Faster local NVMe will not help a virtual disk that still lives on an overloaded shared array.

NVMe speeds up short operations when they reach the drive

The practical gain from NVMe is clearest when a user waits for a chain of dependent reads or for a log write to complete. Examples include posting a document, searching an index that is not fully cached, opening a record after a long idle period, writing many rows, and running a sort that spills into the temporary database. Latency per operation matters more here than maximum megabytes per second.

The NVMe protocol was designed for nonvolatile memory attached through PCI Express. The NVM Express overview describes many queues and a shorter software command path than older storage protocols. That headroom is particularly useful at high concurrency, but an accounting database for 100 users rarely keeps tens of thousands of requests queued. Compare queue depths of 1, 2, 4, and 8. A vendor result at QD32 or QD128 answers a different question.

Consider a document posting operation that still needs four dependent reads and one synchronous log flush after part of the data reaches cache. When every stage waits for the previous one, high bandwidth cannot merge them into a single operation. Cutting a fraction of a millisecond from each access shortens the whole chain. In a bulk job, the effect accumulates and releases worker threads sooner.

Opening a warmed-up reference list may not improve at all because the data comes from memory. A heavy report will not necessarily become proportionally faster either. CPU, a poor plan, blocking, or transfer of the result to the client may be the limit. Backup and restore usually depend more on sequential throughput and on the other end of the path, such as the network or target array.

In my experience, users notice the disappearance of occasional pauses more than a reduction in average form-opening time from 0.8 to 0.6 seconds. Look for a lower mean and a tighter spread under mixed load when evaluating NVMe. An enterprise drive that responds consistently is more useful than a client model with a high burst and steep drops after its cache fills.

Compare NVMe SSDs with SAS SSDs, not with an interface

NVMe and SAS name protocols, not memory types, so “NVMe versus SAS” is incomplete without a drive model. SAS may mean 10K or 15K mechanical drives, enterprise SSDs, or an external enclosure with a caching controller. NVMe covers client M.2 drives without power-loss protection and enterprise U.2, U.3, or EDSFF devices with telemetry and endurance intended for continuous load.

When you compare one enterprise NVMe SSD with one modern SAS SSD in the same class, NVMe will usually provide lower latency and more IOPS. When you compare an NVMe drive without power-loss protection with a reliable SAS SSD behind a controller with protected cache, the winner for write safety is no longer obvious. When SAS means a hard drive, the random-access difference is fundamental: mechanics must move a head, while solid-state storage does not.

SAS has qualities that a single-database benchmark does not reveal. Dual-port drives can provide paths through two controllers or two nodes. Administrators know mature RAID controllers, enclosures, and hot-swap procedures well. These are sound reasons to keep SAS in a high-availability cluster or an existing shelf when its latency already meets the requirement.

Direct-attached NVMe uses a different architecture. Each drive consumes PCIe lanes, while software RAID or platform facilities do work that a dedicated controller often handles in a SAS configuration. The server must route enough lanes, boot from the chosen layout, expose drive health through the BMC, and handle hot replacement correctly. Four physical bays do not guarantee four independent connections at full bandwidth.

Data sheets are useful for confirming the device class. For example, the Samsung PM9A3 enterprise specification lists PCIe 4.0 x4, power-loss protection, 1 DWPD for five years on U.2 models, and performance that varies by capacity. That does not promise any particular speed for your database, but it shows the type of details missing from an ordinary client SSD description. Look for the same set on a SAS SSD: endurance, sustained random writes, cache protection, sector format, two ports where required, and controller compatibility.

Average latency hides the pauses an accountant sees

Choose storage by its latency distribution because an average hides occasional long responses. If 99 operations complete quickly and the hundredth takes tens of milliseconds, the mean may still look acceptable. The user whose document lands in the long tail sees a freeze. Under concurrent work, those tails overlap with blocking and multiply the effect.

For SQL Server, Microsoft recommends inspecting latency through sys.dm_io_virtual_file_stats and the PAGEIOLATCH_*, WRITELOG, and IO_COMPLETION waits. Microsoft's guidance calls sustained values above roughly 10 to 15 ms a sign of trouble, not a target for a new SSD. That distinction matters. The threshold helps troubleshoot mixed systems, but I would not procure modern local solid-state storage with planned latency near that level.

Separate files by their I/O pattern. Data files produce random page reads and writes. The transaction log depends on sequential synchronous writes and a guarantee that data reached durable media. The temporary database receives sorts, hashes, and intermediate results. Backups create large sequential streams. A single average for the D: drive where everything resides will not tell you which path delays document posting.

“Separate the files” also needs precision. Two logical volumes on one set of drives help with capacity management and observation, but they do not create two independent media queues. A dedicated log volume helps when it has an independent protected resource behind it or when the controller layout gives it predictable bandwidth and latency. On a small server, one fast RAID 10 array sometimes works better than two weak arrays where the log gets only a pair of slow drives.

The same rule applies to tempdb or another database engine's temporary area. Moving it to fast NVMe helps when measurements show physical writes from sorts and hashes. If internal database structure contention causes the wait, a separate drive will not remove the cause. Match waits to bytes on a specific file before changing placement.

Check at least four latency values: mean read, mean write, p95, and p99. Add IOPS and MB/s, but do not substitute them for response time. Repeat the measurement with the drive at its normal fill level and after sustained writing. Some SSDs absorb data quickly into free internal cache and respond much more slowly after it runs out. A database runs for years, not for the first five minutes after a drive leaves its box.

Watch the queue depth. A deep queue helps a drive show its maximum IOPS, but it also means requests are already waiting. For an interactive system, a good result at QD1 to QD4 is often more useful than a record at QD128. Run a high-depth test separately to measure headroom for a peak, array rebuild, and background jobs.

Size write endurance from the log and maintenance work

Calculate endurance from actual writes to the device, not from database growth. A database can grow by 20 GB while rewriting pages, the log, temporary files, and internal structures several times in the same day. RAID, SSD garbage collection, and write alignment also change the physical amount. A forecast based only on the information-base size is usually too low.

Manufacturers specify TBW or PBW, the total allowed writes, or DWPD, the number of full drive writes per day during the stated warranty period. The conversion is simple:

allowed daily writes = drive capacity × DWPD

A 3.84 TB SSD rated at 1 DWPD allows 3.84 TB of writes per day within the vendor's stated term and workload profile. A 0.3 DWPD rating for the same capacity gives about 1.15 TB per day. This is not an instruction to run the drive at its limit. Leave headroom for peaks, rebuilds, changes in workload, and differences between the vendor's rating conditions and your write pattern.

Collect write counters over at least one complete business cycle that includes month close. On Windows, correlate volume write bytes with database statistics and drive SMART telemetry. On Linux, use block-device counters and the Data Units Written field from the NVMe log. Measure the change, not the lifetime value since manufacture. Record backup volume, index rebuilding, and antivirus scanning separately if it touches the database path.

Buying the highest DWPD rating is also a mistake. An accounting system with moderate writes and a large active data set may run for years on a read-intensive enterprise SSD. Money may be better spent on redundancy, memory, or a second node. But I will not put a client SSD with an unclear rating, no power protection, and unpredictable full-drive behavior under a transaction log, even when its paper TBW calculation appears sufficient.

Monitor the wear indicator regularly. For NVMe, this means Percentage Used and related SMART fields; for SAS, the available set depends on the vendor and controller. Trigger an alert before endurance is exhausted, not after the drive enters a critical state. Planned replacement costs less than investigating rare write errors.

Controller behavior and write protection beat peak IOPS

A database engine needs an honest acknowledgment that a synchronous write will survive a power loss. If a drive or controller reports success while data remains in unprotected volatile cache, a quick benchmark looks excellent, but an abrupt outage may leave a torn page or a missing transaction.

Microsoft's SQL Server I/O guidance requires guaranteed delivery to stable media, correct write ordering, and stable caching. The document specifically warns about caching without protection. I agree with that strict requirement: a UPS helps, but it cannot replace protection against a failed power supply, controller, firmware, or server after an acknowledgment and before the physical write.

In a SAS design, verify the RAID controller model, firmware, battery or supercapacitor condition, write-back policy when protection fails, and support for the chosen drives. A good controller automatically switches its cache to a safe mode when the protection module is faulty. Performance falls, but a battery fault does not become a hidden data risk.

An NVMe design may have no separate hardware RAID controller. It then needs enterprise drives with power-loss protection, correct flush-command support, appropriate software RAID or operating-system mirroring, and monitoring for every drive. Hardware NVMe RAID exists, but it adds cost, its own latency, and another compatibility matrix. Do not buy it from habit. First identify the function it must provide that the platform cannot deliver another way.

RAID 10 is usually easy to reason about for a transactional database: a mirror survives one drive failure, and striping distributes load. RAID 5 or RAID 6 saves capacity, but writes require parity work and rebuilding a large SSD creates sustained mixed load. There is no universal ban on RAID 5, but for an active database on four drives I prefer the explainable performance of RAID 10 when the budget accepts half of the raw capacity.

A two-drive NVMe mirror often has enough performance for a database at this scale, but it lacks the capacity headroom of a four-drive RAID 10 set and different implementations schedule reads differently. Check which member your software or hardware mirror reads from, how it reports failure, and how long it rebuilds at a realistic fill level. Empty-mirror speed does not answer those questions.

Walk through the failure path before procurement. Remove one drive from the test system through the supported procedure, confirm that the database continues to run, make sure monitoring sends an actionable alert, and verify that the administrator can map the logical identifier to the physical bay. After replacement, measure p99 during rebuild and run the database engine's consistency checks. A red light without a targeted notification is little help at night, and incorrect bay labels can turn a single-drive replacement into a full array outage.

Array redundancy does not replace a backup. Operator error, database-level corruption, and ransomware can affect every mirror. Keep separate tested copies and perform regular restore drills. The drive interface does not change this obligation.

NVMe needs planned PCIe lanes and airflow

Design an NVMe server as a complete system because drives need PCIe lanes, a compatible backplane, power, cooling, and management. An adapter that physically accepts U.2 or M.2 does not create missing lanes or add hot swap. Teams often discover this only after purchase when some slots require a second processor that was not installed.

Map the connections: which CPU serves each slot, whether a PCIe switch is present, whether drives share bandwidth with a network adapter or accelerator, whether the board supports bifurcation, and whether the BMC can see drive health. Four PCIe 4.0 x4 drives need the corresponding lanes and routing. The accounting database may never consume all that bandwidth, but a topology error can disable a drive or route traffic over the interprocessor link.

Cooling cannot be an afterthought. An enterprise U.2 NVMe drive under load consumes roughly ten watts or more in a small enclosure. The PM9A3 specification, for example, lists average active power up to 13.5 W depending on capacity and operation, with an operating limit of 70 °C. This is not a universal limit for every model. It is a reason to read the thermal section of the exact data sheet and measure temperature in your backplane.

Thermal throttling looks like a puzzling performance drop: the first few minutes are fast, then latency rises without an obvious error. Record temperature and throttling flags alongside p99, sustain the write long enough, and test the server room's worst summer condition. Two empty bays nearby do not guarantee airflow when the chassis duct was designed for another backplane.

SAS drives also have temperature requirements, but the 2.5-inch enclosure ecosystem is usually more predictable in older servers. The extra RAID controller, however, produces heat and needs airflow. Add drives, controller, CPUs, memory, and network adapters together when calculating power and cooling.

Cost per terabyte includes usable capacity and headroom

The price of one drive is the wrong comparison. Calculate the cost of a complete redundant storage path per usable terabyte. Include drives, backplane, controller or PCIe switch, controller feature licenses, cables, a second node where required, a spare drive, support, and power. Four 3.84 TB drives in RAID 10 yield about 7.68 TB of raw usable capacity before formatting, filesystem reserve, and SSD free-space allowance.

Free space is operational capacity, not decoration. The database grows, maintenance needs temporary room, and an SSD sustains writes more consistently when internal reserve and unallocated space remain. I budget projected growth, room for temporary operations, and operating headroom separately. The percentage depends on the database and its maintenance routine, so a fixed rule to “always leave 30 percent” is less useful than a calculation based on observed growth and the largest maintenance operation.

Use this formula to compare designs:

cost per usable TB = total storage-path cost / capacity available to the database after RAID and reserve

Add the cost of downtime. A cheaper array without an available spare or an administrator who knows it may cost more at the first failure. On the other hand, four high-endurance NVMe drives are hard to justify when the database uses 400 GB, nearly all of it fits in memory, and writes consume only a small fraction of their rating.

SAS often wins in infrastructure you already own: a compatible shelf, controller, and spares exist, and staff know the replacement procedure. NVMe often wins in a new server because it has fewer intermediaries, greater performance density, and lower latency. Compare both at the same redundancy and support level. One NVMe drive against four SAS drives in RAID 10 produces an impressive but useless chart.

Licensing may also change the total. If faster storage reduces query time but the server still needs the same processor licenses, there is no direct license saving. If the old array forced you to keep an extra node or excessive memory to mask disk behavior, a new design may reduce overall cost. Calculate such effects separately and do not attribute them to the drive without evidence.

Compare the component support windows. The drive, controller, backplane, firmware, and operating system must coexist in one compatibility matrix. A cheap retail drive may require manual updates, hide telemetry from the BMC, or make fans run at full speed because the system does not understand its sensor. The purchase price stays low while the operating cost rises.

A test must reproduce the working queue, not the drive advertisement

Test candidates on a data copy and a dedicated test volume with a pattern close to production. A synthetic test shows the storage ceiling and latency, while a typical application run shows whether that ceiling gives users a faster response. Neither result replaces the other.

On Windows, Microsoft's DiskSpd utility lets you set block size, write mix, random access, threads, queue depth, and percentile reporting. The following command creates a 20 GB test file, runs random 8 KB operations with 30 percent writes, uses four threads at a queue depth of 2 per thread, warms up for 30 seconds, and measures for 120 seconds:

diskspd.exe -c20G -b8K -r -w30 -t4 -o2 -W30 -d120 -Sh -L D:\io-test.dat

Run it only on an empty test volume because it creates and changes a file. In the result, find the total, read, and write tables with IOPS, MiB/s, and mean latency, then the Percentile section with p95 and p99. Repeat at -o1, -o4, and -o8, and run a separate sequential 8 KB write test for the log with one thread and queue depth 1. Do not combine those results into one average.

Next, capture latency for the database files themselves. For SQL Server, use this query:

SELECT
    DB_NAME(vfs.database_id) AS database_name,
    mf.type_desc,
    mf.physical_name,
    vfs.num_of_reads,
    CASE WHEN vfs.num_of_reads = 0 THEN 0
         ELSE vfs.io_stall_read_ms / vfs.num_of_reads END AS read_ms,
    vfs.num_of_writes,
    CASE WHEN vfs.num_of_writes = 0 THEN 0
         ELSE vfs.io_stall_write_ms / vfs.num_of_writes END AS write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
JOIN sys.master_files AS mf
  ON vfs.database_id = mf.database_id
 AND vfs.file_id = mf.file_id;

The counters accumulate from instance startup, so save a starting snapshot, run the same operation package, and calculate the difference. At the same time, measure login, record opening, document posting, a bulk job, and a heavy report. If NVMe reduces storage p99 but the operation does not improve, look for the next constraint in database waits, CPU, memory, blocking, or the network.

Do not transfer a result between different protection layouts. A test of one bare NVMe drive does not describe a mirrored pair, and a SAS SSD test with protected write-back enabled does not describe a controller with a failed battery and cache disabled. The final run must use the same firmware, RAID, cache policy, fill level, and cooling that the production server will use.

The application test needs identical source data. Restore the same backup to both configurations, warm them with the same workload, and reset accumulated counters before the measured run. Do not clear cache before every action if employees normally use a warmed database. Run a separate cold test for startup after maintenance, but keep it apart from the normal day.

Record the median operation time and slow attempts, not one lucky run. Run a background task concurrently if it really overlaps the production peak, such as an exchange job or backup. Artificial maximum-rate writing reveals the limit, but it may create a queue that production never sees. The test should reproduce the complaint and verify headroom, not force interface saturation.

The choice comes down to three testable cases

For a new on-premises server supporting an accounting system with 100 users, a sensible starting point is enterprise NVMe with power-loss protection, mirroring, and separate tested backups. This provides low latency, useful peak headroom, and no need for a large drive count merely to obtain IOPS. Measurements determine capacity, DWPD, and drive count; the user count does not.

Choose SAS SSD when the server or high-availability design already uses a compatible dual-port enclosure, access from two controllers is required, and measurements confirm acceptable p95 and p99. Replacing a sound design merely to use the NVMe name has no purpose. When upgrading, compare the full storage-path cost and make sure the SAS controller will not limit the new SSDs.

Keep SAS hard drives for backups, archives, and rarely read data. They suit active transactional database files only when the load is very light and measured latency supports the choice. Savings per terabyte disappear quickly when month close puts random requests into a queue.

A short decision matrix can end arguments about a preferred interface:

• For a new standalone server or pair of nodes, choose enterprise NVMe with power protection when tests confirm shallow-queue p99, mirror behavior, and safe temperatures.
• For an existing dual-controller SAS enclosure, choose compatible SAS SSDs when tests confirm latency on both paths and acceptable behavior during a controller failure.
• For inexpensive archive capacity, retain SAS hard drives or another capacity tier when it meets the backup, restore, and verification window.
• If the database sits almost entirely in memory and storage does not limit the slow operation, keep the current layout until measurements say otherwise.

Treat migration as a storage change, not as an ordinary directory copy. Prepare a verified backup, estimate restore time, agree on the outage window, record file and cache settings, and run the database engine's integrity check after the move. Do not erase the old array until acceptance and a successful backup from the new system. The rollback plan must identify the point after which new transactions cannot simply be sent back to the old copy.

For a new infrastructure project, GSE can select S200 servers and integration around the required drive topology, cooling, support, and local-production requirements. Even a suitable platform does not replace the baseline: save a full day of metrics before specifying it, include the peak operation, and test the candidate with the same scenario.

The purchase decision should fit in a short record: current p95 and p99, write volume and mix, active data set, required usable capacity, failure-protection layout, durable-write guarantee, PCIe or SAS map, and temperature under sustained load. If a supplier cannot fill in those fields, the IOPS figure on the first page of a data sheet will not rescue the project.