I did some Googling and couldn't find an answer to this question more recent than a few years ago, so I thought I'd ask. Oracle's RAC feature offers load-balancing for both read and write transactions, as well as scale-out and high-availability without downtime (at least, as I understand it - we're about to deploy our first databases that use RAC, so we'll see how it goes).

Is there any SQL Server feature set (or third party component you could install on top) that delivers equivalent functionality? We've always used Windows clustering, where a failover event causes about 20-30 seconds of SQL downtime - always tolerable, but not ideal. Now, with AlwaysOn in SQL 2012, SQL Server shrinks that to about 15 seconds and adds the concept of read-only-secondary databases, but they still require that write transactions are choked through a single connection point (much improved, since many transactions are just read, but still not really load balancing), and in the case of a node failure or the need to patch, there's still downtime.

I suppose it's just more curiosity - I feel like this is the only area that SQL Server falls behind Oracle (at least among the features I've personally seen used). I wanted to see if there are any options out there to close that gap and possibly improve our own SQL Server deployment while we wait for Microsoft's equivalent feature to be added - maybe in SQL 2014/2015?

  • 1
    I'm not sure SQL Server is really falling that far behind Oracle. Well, yes it has a feature SQL Server doesn't, but be sure to revisit this thread after you've been running it for a few months and let us know if it's all roses or not. :-) I don't have experience with it either but colleagues that do have not always had nice things to say about it. Jul 13, 2012 at 22:06
  • 2
    Also I hope you don't expect any accurate speculation about features in future versions of SQL Server. Those who know whether or not there are any such features in the planning phase can't tell you; those who don't can't tell you either. :-) Jul 13, 2012 at 22:10
  • 1
    @AaronBertrand: Fair enough, I don't really expect any feature speculation, as I realize it wouldn't be accurate at all. While AlwaysOn is an improvement (in some cases), I had higher hopes that it would more closely replicate RAC's functionality and close that gap. MSSQL does a number of things better than Oracle, in my opinion, but this is one area where Oracle holds the baton, in my opinion.
    – SqlRyan
    Jul 13, 2012 at 22:44
  • 1
    @rwmnau again, I suggest you hold your glowing praise of RAC until you've implemented it and have used it for a few months. :-) You might be right; it might be everything it promises and work perfectly for you. But you might be bamboozled by the shiny glitter on the box. :-) Jul 14, 2012 at 2:51
  • 2
    @AaronBertrand: Ha, point taken. I've heard a number of criticisms, like that it's too sensitive about network latency and it's quick to evict nodes and the such, so I'm definitely holding total judgement until after we've rolled it out and I've used it firsthand. SQL Server, while it has a number of HA option, didn't seem to be moving into the "multiple writable front end" space. Maybe I'm about to discover the reason why :)
    – SqlRyan
    Jul 14, 2012 at 8:05

5 Answers 5


No, nothing in SQL Server can give you the same thing out of the box.

Currently, the only SQL Server technology that allows simultaneous writes at multiple nodes is Peer-to-Peer replication. Note that I did not to say "write scale-out," because it works in a way such that the entire system has the write capacity of only a single node. The introductory paragraph of that page is worded carefully to include the term "scale-out" without saying "write scale-out." Yay for marketing-speak.

From what I've read, Oracle RAC is the same in that respect. Functionally, the only thing that's missing from SQL Server in this configuration is a load-balancing solution, which is both an advantage (you can implement it any way you want) and a disadvantage (it's not in the box or supported by Microsoft) when comparing against competing products.

Conversely, Oracle RAC does not give you the same thing as SQL Server out of the box either. For example, RAC is recommended to be implemented with nodes within 100km of each other because of realtime network latency, whereas Peer-to-Peer replication has no such restriction. (I'm not saying one solution is better than the other: I'm just pointing out that they are different. The business should choose a solution that best fits their specific needs.)

  • 1
    The main reason for the 100km thing is because Oracle remains ACID compliant across nodes - they need to communicate with each other over a high speed interconnect & the speed of light becomes an issue. SQL Server in a similar config propagates changes & you can get row level conflicts if two nodes update the same row within a certain period of time - not ACID - not a single database. A set of RAC instances are a single database, that's the distinction.
    – Philᵀᴹ
    Jul 14, 2012 at 20:50
  • @Phil: Yep, that was my point -- they are different.
    – Jon Seigel
    Jul 15, 2012 at 15:44

I'm a DBA supporting both SQL 2000-2012, Oracle 11g, and Oracle 11g RAC.

IMO, Always On Availability Groups in SQL 2012 comes very close to the availability and scalability of RAC at much less cost in both dollars and complexity. You can scale out reads by querying against the mirrors, but you'd want to direct all DML to the primary server (SQL Server mirrors can't be updated). If the primary SQL Server crashes, failover to one of the mirrors is nearly instantaneous. RAC experiences a similar pause if a node crashes as uncommitted transactions on the failed node are rolled back by the surviving node.

The biggest advantage (IMHO) of SQL 2012 AAAG over RAC is that it's a shared-nothing architecture. RAC shares the storage. If that fails, the entire cluster is down. That is a huge SPOF in RAC that everyone seems to forget about. If you want to protect yourself against that, you need to set up a standby server. If you want that to be RAC, the cost just gets compounded ever further.

  • 1
    Good point on the SPOF of RAC. Mar 25, 2013 at 16:48

The straight answer to your question is no, SQL Server does not have equivalent functionality. There are aspects of SQL Server that give you the kind of failure tolerance that you want (even as far back as SQL Server 2005 when using DB mirroring and a mirror-aware application), but there is not a 1:1 with Oracle RAC.


A better comparison of AlwaysOn would be Oracle's Data Guard feature. Active-Passive clustering. (yes, you can read from standby, but it is read only, so still only one node is active")

Oracle RAC is a completely different animal, and active-active clustering. I did not see any moves if Microsoft will ever want to implement that.


SQL Server 2012/2014 with AlwaysOn adds a lot of capabilities that get you close to Oracle RAC - and in some cases improve on it. (Recall that with RAC, you need to be using Oracle app server, weblogic, and JDBC - plus operating in a single data center and the app can connect to only one RAC cluster - shared storage means RAC doesn't work in the cloud).

With AlwaysOn you get read-only secondaries (4 in 12, 8 in 14) and auto failover support. A few things are challenging though - AlwaysOn does not support load balancing - unless you write a script, it'll always draw the first server on the list. Failover also impacts the app - it's not transparent so apps may have to be restarted.

Full disclosure - I work for a company that makes software that augments AlwaysOn. Our database load balancing software front ends SQL Server - it does read/write split on behalf of the app, does response-time based load balancing that spans data centers, and queues inbound writes/transactions during failover so that apps don't see errors. See how Microsoft, Dell, Quicken Loans, and other enterprises are using ScaleArc software to augment SQL Server AlwaysOn and get RAC-like capabilities with no app changes.

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