(Replying to PARENT post)

I assume that the linked blog intended to link to http://msdn.microsoft.com/en-us/library/cc645993(v=sql.120)....

SQL Server has been getting much more expensive because their current userbase is captive (meaning the cost, complexity and risk of migrating to another database system is enormous because of a heavy integration with SQL Server specific features). I don't imagine a large number of new systems are being built around SQL Server, apart from those at shops that are already captive.

It is an excellent database, but I do get a chuckle that by far the greatest benefit being pushed for SQL Server 2014 is in memory tables (which is something that SQL had -- at least for temporary tables -- back in the 6.5/7.0 era, but then had removed). While it is hardly identical, an approach we did on one team is to have SQL Server take 64GB (note that it is per instance, and most server deploys see many instances on a single server, so that isn't quite as prohibitive as it might sound) and then have an enormous RAMDISK on which tempdb would be created. Made use of the RAM, and saved enormous amounts of IO (tempdb is the weak link of almost all SQL Server platforms, as everything hits it, especially if you make use of snapshot isolation / row versioning).

👤corresation🕑12y🔼0🗨️0

(Replying to PARENT post)

> I assume that the linked blog intended to link to http://msdn.microsoft.com/en-us/library/cc645993(v=sql.120).....

Great catch - fixed, thanks.

> greatest benefit being pushed for SQL Server 2014 is in memory tables (which is something that SQL had back in the 6.5/7.0 era, but then had removed)

Sorta kinda - back then, we had DBCC PINTABLE, and it would cache the data, but it would still require that the transaction logs and data pages be written to disk. Now with Hekaton, you can specify that a table never hits disk, ever. (Don't get me wrong, I don't think people are going to adopt that particular feature due to other limitations around datatypes and supported syntax.)

👤BrentOzar🕑12y🔼0🗨️0

(Replying to PARENT post)

I would guess that SQL Server has been getting more expensive largely because the people who decide these things see themselves as competing with Oracle more than with free alternatives, and (I believe) SQL Server is still cheaper than Oracle.

Disclaimer: I work at Microsoft in "the SQL org" but I'm just a peon so what do I know?

👤CurtHagenlocher🕑12y🔼0🗨️0

(Replying to PARENT post)

Microsoft's BizSpark (free software like SQL Server for startups and free credits for Azure) is chugging along. They're at least making an effort to convince new startups to build on their stack.
👤eli🕑12y🔼0🗨️0

(Replying to PARENT post)

They think we're captive. We're mostly not these days.

We have our platform going through testing against Postgres and SQL Server at the same time thanks to the use of NHibernate. We have already done a successful trial migration which moved an entire vertical subsystem over.

There are a few issues to iron out but we can switch out.

We're not paying for SQL 2014 having been totally fucked over for SQL 2012 licenses due to the CPU to Core license change and our hefty DB cluster has lots of cores.

👤harrytuttle🕑12y🔼0🗨️0

(Replying to PARENT post)

I thought (although I could easily be mistaken) that one of the big features about SQL Server 2014 was its lock free tables [1].

[1] http://sqlserverrider.wordpress.com/2012/12/31/hekaton-recap...

👤chacham15🕑12y🔼0🗨️0

(Replying to PARENT post)

All tables in sqlserver will be memory resident if there is available ram. But it happens dynamically, or is non-deterministic if you like. I assume the in memory feature allows you to force a table into ram and force it to stay there.
👤adamconroy🕑12y🔼0🗨️0