This question already has an answer here:

I am using Windows Server 2008 Enterprise with SQL Server 2008 Enterprise. I am considering whether using SAN or using NAS is better to store database data files. Are there any industry readings to compare whether NAS or SAN is better for database storage scenario?

Besides my database storage scenario, any industry readings to compare SAN with NAS to see which technology is better suitable for which scenario?

thanks in advance, George

marked as duplicate by Chris S Jan 22 '14 at 14:29

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 2
    SMB does not support locking semantics required by database management systems. Database volumes on SMB shares do not work at all. SMB based NAS is a non starter for this application. – ConcernedOfTunbridgeWells Jul 1 '10 at 14:12
  • 1
    By contrast, note that NFS does support the appropriate locking semantics and Oracle on NFS shared volumes does work. You can even find white papers about it on Oracle's web site. – ConcernedOfTunbridgeWells Jul 1 '10 at 14:13

We had your previous question on this subject yesterday and it's pretty conclusive that even IF you can get SQL to store it's data via NAS protocols such as SMB/CIFS or NFS it's a really bad idea!

So that should discount using SMB/CIFS and NFS from the equation, let's look at the other options.

If there's no need for clustering then most people would agree that suitably well spec'ed local (Direct Attached Storage - DAS) with the right RAID level is the best both interms of performance and value.

If you are clustering then you need a block-level SAN/NAS system (you may also just want the snapshotting features some of these arrays offer too of course) - these are typically Fibre-Channel (which uses a dedicated storage-tuned network, is very fast and performance-consistent - but expensive), iSCSI (which uses standard ethernet networks, is generally slower than FC but is often 'fast enough') and the kinda-hybrid Fibre-Channel-over-Ethernet (which is a nice, but very new, compromise between FC and iSCSI).

Generally large organisations who rely on their DBs use FC and would only use iSCSI for less important work; for small organisations iSCSI can ofen provide perfectly-adequate performance for much better value (and less complexity) than FC - 5-10 years from now FC will be dead once FCoE has matured.

Hope this helps.

  • 1
    +1 - SQL server volumes on SMB shares are known not to work. – ConcernedOfTunbridgeWells Jul 1 '10 at 14:11
  • 1
    @CoTW - apparently they can just about be fooled into working but it's a super bad idea and is almost certain to fail pretty soon. This user asked a similar question yesterday - I have a horrible feeling he's bought a NAS for the job gulp – Chopper3 Jul 1 '10 at 14:14
  • 1
    Just to be a bit more precise, a SAN always export a block device, instead a NAS export alwasy a file level storage (a file system - think about NFS, SMB). – PiL Jul 1 '10 at 14:16
  • 1
    @Pier - If that's true, what about NAS devices that can present LUNs via iSCSI? Where do those fit in? – EEAA Jul 1 '10 at 14:25
  • 2
    Maybe 'Known Anti-Pattern' would be a better description. Some years ago I saw a white paper from Oracle on the subject - NFS locking semantics will support database volumes correctly but SMB will not. Maybe you can get SQL Server to do this, but Oracle (at least) flat out state that SMB is not up to the job. – ConcernedOfTunbridgeWells Jul 1 '10 at 14:25

I wouldn't expect so - they are very different products aimed at different markets. SAN at the top end, NAS at the bottom end.

Although recently it has become feasible to use NAS for database storage (but probably only with iSCSI over 10Gb ethernet) I'd recommend staying away from it and using fibre or SCSI attached storage.


  • 4
    Whether a storage device is a SAN or NAS does not put it into the "top" or "bottom" end. There are very good and very poor devices of each class. The only definitive difference between a NAS and SAN is that (typically) NAS devices serve at the file level, while SAN devices serve up block level. That said, there are many devices out there now that do both, so the line between NAS and SAN is getting blurred. – EEAA Jul 1 '10 at 14:04
  • 1
    Agreed, NAS topologies aren't best suited for DB type stuff. iSCSI falls under the SAN category though, doesn't it? – churnd Jul 1 '10 at 14:06
  • 1
    @churnd - typically yes, though I'd argue against the notion that the OP would need 10GB Ethernet in order to run iSCSI. It completely depends on the workload. There are many companies I know of that are running their SQL DBs very happily over iSCSI/1GB. – EEAA Jul 1 '10 at 14:08
  • 1
    Erik - I'd contend that a NAS is more about usage over a shared network, although your block/file argument is also an important one - I guess we have a little boundary-blurring right now :) – Chopper3 Jul 1 '10 at 14:10
  • 1
    @Chopper3 - yes, that's an important distinction as well, though as you mentioned, iSCSI throws a wrench into that... – EEAA Jul 1 '10 at 14:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.