Is SQL Server Losing Mindshare?

As many of you have noticed, I have been flirting a lot with open source database lately. I am no longer spending much time going to SQL Server conferences.

About two years ago, I decided that it is time to diversify my knowledge and spend more time with other database products. Back then, this was largely based on a hunch that Open Source is now getting to the point where it is worth looking into. I didn’t really have any data to back up my decision to lower my investment in SQL Server – it was mostly intuition, a feeling for the zeitgeist.

Today, I wanted to asses where things are. It is difficult to get information about the popularity of databases that is not heavily biased, so I decided to mash up some data myself.

The Data Source

These days, one of the main sources of information about database is dba.stackexchange.com (referred to as SE from now on). All the cool SQL Server guys hang out there (and some of the not so cool ones, including myself). Question about MySQL get answered quickly, Postgres questions are frequent now. Fortunately, it is possible to download all this SE data in an easy to read XML file from here:

Based on the information in there, we can analyse things like:

  • How many questions get asked about each database?
  • What activity happens on those questions?

Admittedly, answering these questions is a rather crude way to measure the popularity of databases – so take this with a grain of salt. For example, a lot of SQL Server knowledge flows on forums on the web and never touches SE. Nevertheless, when novice people ask a questions in a known forum of experts where they can expect an answer, I think the amount of questions asked and the interest in them is a pretty reasonable indicator of interest. It is almost certainly less biased than some sponsored report by one of the big analyst agencies (and I use the term “analyst” lightly).

Analysis

Based on the XML data, you can quickly mock up an analysis. For those of you interested in reproducing or extending the analysis, I will add the script in the comments.

Here follow the analysis in the time period from January 2011 (where SE took off) until April 2014.

Questions Asked

First, I analysed how many questions have been asked about each database to date. This is to get an idea of the built up knowledge SE stores:

image

(note: SQL Server questions also include Analysis Services)

Clearly, SQL Server is in the lead here. More questions have been historically asked about it than about any other database. We can also see that MySQL is the most popular of the Open Source databases. NoSQL and others barely shows up in the data, though I suspect NoSQL users often look at other places than SE for answers so this may be an unreliable indicator.

So far, it looks like my intuition is wrong. SQL Server is the dominant database out there.

But not so fast. Let us instead look the number of questions asked per month:

image

The picture is less clear now. MySQL and Postgres are clearly gaining in popularity, while SQL Server seems stagnant.

Comments

Questions are not the only indicator of community engagement. Comments also indicate interest. The SE data dump provides those too:

image

Trends here are a little less clear. A stacked plot shows it better:

image

SQL Server is holding its lead position on engagement in the SE comment section. Seeing how much activity there is on still controversial subjects (like heaps vs. clusters and GUID vs. IDENTITY) – this is not surprising.

Answers

Continuing the analysis, we can have a look at how good the community is at providing answers to questions. Here are the answers per month:

image

The strong SQL Server community is clearly seeing some challengers from MySQL and Postgres. There is a clear drop-off in answer activity recently on SQL Server.

And here is the average time it takes to get an answer:

image

Looks like those Oracle people haven’t fallen asleep over their Exadata machines just yet…

Summary

I have previously stated that I think SQL Server is losing mindshare in the database community. From this simple analysis of SE data, it looks like there is indeed some traction in the open source community that can pose a serious threat. MySQL is going strong, and Microsoft would be wise to fear it.

Competition is good for us consumers of databases and I am happy to see that the open source community is finally catching up. I am also happy to have spent more time with open source databases to see it happen from the inside.

The Future

Looking at the crystal ball, I can see the market for relational databases change dramatically if the players modify the way they operate. Here is my not so humble advise to the communities and corporations.

Microsoft:

Start listening to your high end customers who know what they are doing. They can lead the way to the features the small customers will love.  Stop wasting time developing stupid features no-one who knows what they are doing need (ex: Everything “Beyond relational”, Tabular models, 10 different ways of writing reports). SQL Server 2014 is finally showing some signs of fixing bugs that are 5-10 years old. Taking that amount of time to fix stuff is simply not acceptable and you are losing your customer base because of it. Stop closing Connect bugs as “by design” when you can’t be bothered to fix them, because it is immensely disrespectful of the people who really DO know better and who think that if this is your “design” – you don’t. Fix whatever is wrong with your development organisation to speed up bug fixes rates.

Management studio does not need to be released in band with the core engine. This application is what makes SQL Server the “iPhone of Databases” and it needs to work flawlessly (it doesn’t).

SQL Server was positioned to completely rule the database market – this eminently defensible position is being squandered and a multi-billion dollar business is going down the drain. Wake up Microsoft, the enemy is at the gates!

Stop innovating, start fixing!

MySQL Community:

You need to come to terms with the fact that your toy database, even though it runs Facebook, still does not hold a candle to Oracle and SQL Server in the Enterprise. Web 2.0 is not going to make big, corporate IT go away. Who do you think funds all those adds and buys all the data that powers Google and Facebook? If you want respect in the corporate market you need to change the tune you play.

Manageability (Thanks Percona), query parallelism that just works “out of the box” and a good optimiser than can do all join types is absolutely crucial. Single threaded index build is simply embarrassing – you should know how to do parallel sort.

Backup/restore is too bloody complex – you need a simpler, unified solution (see SQL Server). You need mirrors, cluster and other HA features to simply work and be part of the core release (again, see SQL Server).

The features and performance optimisations you are building into the core product have been around in SQL Server 1998. Claiming you can do what it can do, simply shows you have not studied SQL Server very well (see previous comment on toy databases and changing your tune). All the forks (Maria, Percona, Oracle, Toku etc.) are not helping you. It makes running MySQL and keeping up with releases and fixes a nightmare and it slows everyone’s development speed down. You are at least 10 years behind SQL Server and Oracle – so you need all the development speed you can get and an army unified under a single goal. Pool your limited development resources and go take the battle to SQL Server properly.

Postgres Community:

Being ANSI compliant and having a beautiful optimiser (great work by the way!) is not the only thing that matters in the database world. You need to get your basic performance act together. Doing kernel calls into the OS all the time and trusting that the Linux/FreeBSD scheduler, memory manager and I/O system will do the right thing “because Linux is Awesome” is not good enough. SQL Server switched to a user space scheduler and careful memory management in version 7.0 (released 1998) – not because Windows sucked (it did, about as much as Linux does today) but because the first thing you realise when coding for high performance is that the OS gets in your way more than it helps out. This is not a contested insight or a matter of opinion – it is the way performance is done. Go through every single malloc, spinlock, mutex and I/O path and take the optimiser’s mind-set to it. Build scalable data structures and streamline the code base. Snap out of the academic mind set, take performance seriously.  This may mean you have to take bug fixes from a very wide array of people and find new allies. When you can run TPC tests on 2 socket machines with performance on parity with SQL Server and Oracle, you are getting somewhere. Your failure to run TPC well is not due to TPC being an evil test (it is) and Microsoft and Oracle tuning specifically for it (they do) – it is mostly because your data structures came out of a computer science 101 class and are not state of the art. Forks have been done that proves that great performance is possible with Postgres – it can be done and there are some very smart people in the Postgres community.

No matter how hard you try, the optimiser will never be perfect because it heuristically tries to solve an NP complete problem. You need to come to terms with this fact: You need query hints in the core release. This hint/no-hint discussion has gone on in Oracle and SQL Server for 20 years now – the conclusion is clear: Implement hints because the ones who are smart enough to use them right are the people you want on your side. Yes, people will shoot themselves in the foot with them – that is the price you pay for power.

  32Comments

  1. DBAdmin   •  

    Oracle is the greatest database in the world? Seriously? Everything is upper case only. You are limited to 30-character object names. You cannot store or process an empty string because it’s converted to NULL. The data types are kind of crude. The whole system still smells like the 1980s.

    In my limited experience, Oracle appears to be fairly efficient at INSERT operations, but it’s not nearly as efficient (as SQL Server) at SELECT operations. SQL Server pulls data faster from the same size data pool using less hardware. The majority of usage for a typical database is pulling data out, not pushing data in. Who wants a RDBMS with backward priorities?

  2. Peter   •  

    I am late to the party here, but the same issue has been on my mind for a long time now.
    These are my bullet points for Microsoft ( I explain some in detail later in this post):

    1. Fix obvious errors in all parts of the server (like the article mentioned)
    2. Dare to remove bad design decisions from the past.
    3. When introducing new features, focus on those that have solid application for a majority of jour users (else it won’t gain traction and just spawns complains).
    4. When introducing new features, make sure they happily co-exist with existing features and are additive instead of destructive.
    5. Improve the SQL dialect to make it more consistent and make it easier to reuse parts of already written SQL code.
    6. Add data export functions, that can be accessed from SQL. Importing data is decent now, but can be improved upon still with little effort. Make it happen!
    7. Know your user base, I am pretty sure you haven’t got the faintest idea about the majority of your users and what their day to day issues are.
    8. For frequently occurring problems provide index types that can be used transparently as if it is a table, thus converting implementation issues into declaration issues.
    9. Make sure that features that are useful for smaller customers but do not require an Enterprise edition. It is a deadly bad idea to fragment the programmability options that are exposed to applications, simply based on how big a system it is. This one is going to finish you if not addressed on time!

    Now for some details in case some of the points were not immediately clear.

    2. Dare to remove bad design decisions from the past.

    The limit of one cascading operation from table A to table B, forces developers to forgo proper declarative referential integrity on all but one relation.
    Not allowing computed columns to use the result of other computed columns, forces developers to write unmaintainable code.
    Forcing specification of NULL values for null-able columns when doing an instead-of insert or inserting into a horizontally partitioned view.
    Eliminate @@identity…completely or have it behave as scope_identity() as it can NEVER be trusted to return the correct meaningful value (over time)!

    3. When introducing new features, focus on those that have solid application for a majority of jour users (else it won’t gain traction and just spawns complains).

    For sparse columns, a null bitmap (or even better, a default bitmap) is less complex and would be useful in many scenario’s as it has virtually no overhead compared to the current implementation.
    For the output clause, make sure that is essentially a select on the “deleted” and “inserted” views, allows the same syntax and thus also addition of in-line specified columns.
    For the output clause, make that select to client and into a table do the same thing and work in the same situations (now they don’t).
    When allowing tables to be passed from an application to a stored procedure, also allow passing of table variables from SQL.

    4. When introducing new features, make sure they happily co-exist with existing features and are additive instead of destructive.

    The output clause, when not streaming to a table, cannot be used if and only if when there is a trigger on the source table (you have to choose between use of triggers and output clause). Since both are often in the hands of different people they just annihilated BOTH features as a safe and practical building block in any solution. And few will invest time in learning either of them.

    5. Improve the SQL dialect to make it more consistent and make it easier to reuse parts of already written SQL code.

    Allow “insert into x values x=1, b=2”, thus use explicit assignment like you can also do with select as in “select a=1, b=2” and remove the curse that is ordinal specification of values where you could perfectly, if not better do without. Again the output clause does not support “X=inserted.a” style and only accepts “inserted.as as X”, which is inconsistent!

    7 & 9. Know your user base, I am pretty sure you haven’t got the faintest idea about the majority of your users and what their day to day issues are.

    Most software houses are rather small, and contain above average technically capable employees (every company needs a few). They use SQL Server primarily because of it is easy to deploy and support without dedicated specialists. They will be able to make use of most advanced when available to them in an affordable standard edition. But by fragmenting the functionality of the product as a whole and make everything more a then “select * “ only available in enterprise editions. No time will ever be invested by these people in learning and using for them unusable features. As a company you lose mindshare and erode future sales by too aggressively segmenting the product line. No matter how advanced a programming feature you put into the enterprise edition…if it is not in the standard edition, it frankly does not exist!

    8. For frequently occurring problems provide index types that can be used transparently as if it is a table, thus converting implementation issues into declaration issues.

    Easy usable queues and other structures that are presented as a table to the programmer. SQL Server has all the locking in place, it just has to be made more concurrent by using specialized indexed structures underneath. 8. For frequently occurring problems provide index types that can be used transparently as if it is a table, thus converting implementation issues into declaration issues.

  3. Morgan Tocker   •  

    To clarify on MySQL:

    Two of your complaints (backup and manageability) are features that have commercial features from MySQL that are quite well established: Enterprise Backup and Enterprise Monitor. Usage of these tools may be under-represented on Stack Overflow versus other community tools.

    Having said that, MySQL Workbench now also features backup and reporting features that are completely free. The performance dashboard is quite useful: http://www.mysql.com/products/workbench/performance/

    To perhaps answer to another one of your points, significant investment is going into refactoring the optimizer to make it more flexible:

    http://mysqlserverteam.com/the-mysql-optimizer-cost-model-project/
    http://mysqlserverteam.com/sql-parser-refactoring-in-5-7-4-lab-release/

    (Disclaimer; my role is MySQL Community Manager @ Oracle)

    • Thomas Kejser   •  

      Hi Morgan

      I am familiar with the tools. However, you should have a look at SQL Server’s backup API to see just how far this can be taken. Basically EVERYTHING you want to do in backup can be done and scripted very easily from INSIDE the engine. The entire backup API is part of the SQL language used there. It makes things like single database restore to point in time and backup striping over multiple LUN a breeze to implement. The same goes for configuring Mirrors and other HA features. All of this ships simply by installing the product. This is what I call a unified experience.

      I found the MySQL workbench performance dashboards rather lacking. The tool you should have a look at here in SQL Server is Xevents and SQL Profiler. The ability to give you X-ray vision into the engine and exact query behaviour is extremely powerful in SQL Server compared to MySQL and it was one of the first things that frustrated me when switching to MySQL.

      By the way, if you work with the MySQL dashboard creators, could you ask them to please tune the GUI code – that tools is dog slow to work with 🙂

  4. Chis Nelson   •  

    Many of the MSSQL questions on SE are the low hanging fruit that has been answered on MSDN or one of the other forums. Some answers are wrong, (technically correct, but not useful for the situation) and some are quite useful.

    As for Microsoft, they do need to fix all the “design” issues and make the software better. Working in SSIS can be a pain, the interface hasn’t been fixed in the decade since it’s been released and task that should be simple are voodoo or require scripting to the extreme.

    • Thomas Kejser   •     Author

      Chis, I have simply given up on SSIS. There is basically not much I can do in SSIS that I can’t do better in SQL Server using T-SQL. If I was building a warehouse from scratch for an organisation today, I would add a few CLR procedures for the more tricky stuff, but simply build it using T-SQL.

      • DBAdmin   •  

        Amen.

      • JamesNT   •  

        And to think, I LOVE SSIS. SSIS with SSAS and SSRS is awesome.

        But, yes, there are some things MS needs to fix.

        JamesNT

  5. Chris Adkin   •  

    Thomas,

    The race for enterprise dominance is a straight fight between Oracle and Microsoft. The reason Larry bought Sun was simple, he wants to compete in the enterprise space all the way from tin through to shrink wrapped apps, in fact he wants to supply the whole echo system. Additionally Larry wanted full control of Java in the same way that Microsoft does with the .Net echo system. Oracle is a fine RDBMS with an advanced optimizer, more advanced than SQL Server, the problems it has are:

    – Oracle are selling RAC as the silver bullet for everything
    – They are forcing Exadata down people throats, apparently maintaining this is “Patching hell”
    – Like any piece of software the more it evolves the more unwieldy the code base becomes and the software eventually looses its “Clean-ess” of design as more features are bolted on.

    MySql

    The scalability aspects of this aside, the Oracle acquisition of MySql means that its road map has been subverted in order than it does not compete with their flag ship product.

    SQL Server

    SQL Server biggest strength is that it is so easy to use, to quote Wes Brown ( @sqlio ) from a Pass session he presented on solid state technology, “Any fool can install SQL Server and any fool will install SQL Server”. A lot of my gigs and things I have to fix and down to dabblers and the mindset that a .Net developer can be an expert across the full stack, these fallacies get horribly exposed when software has to scale. The other issue is the “Me too” attitude towards their road map, what they should have done instead of roll out Hekaton to a massive fan face is:

    1. Make the SQL Server 2014 large object cache / batch run time NUMA aware.

    2. Introduce SIMD to the database engine

    I’ve been working on a more advanced version of my deck ( the last one you reviewed ), if I create a clustered index on the heap sorted on the date key column I’m using to join to DimDate, then create the clustered column store index on this, this results in a massive performance improvement, a reduction of around 59% in elapsed time, even at a DOP of 24, max CPU utilization across all 12 cores maxes out at 60%. I strongly suspect that if I try your trick of using two instances and splitting the column store between them, I’ll see much better scalability. The point of this is two fold:

    1. Because Microsoft have elected to hit people with a whopping price hike via the core based licensing scheme, they should damn well make sure that with the constraints of all reasonable efforts being expended that 100% core utilization is achievable, this means making the batch mode runtime / large object cache NUMA aware, using SIMD .

    2. Microsoft should have busted their gut to have retained the services of the likes of you, so their is someone pushing the product to its limits, developing bets practice white papers on scalability and performance, feeding back to the development team and keeping them honest. Someone who attended my SQL Bits session mentioned that batch mode scales horribly on a forty core server, to the extent that some cores see no work at all and row mode works better, surely Microsoft should have been on the case before this ?, again who at Microsoft is pushing the poduct to its limits ?

    The other thing I see, and this harks back to Wes Brown’s comments about any fool installing SQL Server is that many larger shops have big problems with SQL Server sprawl, Microsoft should providing the tooling and infrastructure for developing better private cloud / grid style SQL Server estates and migrating sprawling estates into such infrastructures.

    Just my ten cents.

    I would suspect that knowing you as I do, you will largely agree with what I have said.

    Chris

    • Thomas Kejser   •     Author

      Chris, I few comments (and I will add more in the next days).

      First of all, it is not a given that a code base deteriorates over time. The SQL Server team spend a significant amount of effort keeping the code clean and the code is still very readable. If you look in the Postgres source, you will see that it is quite clean too. Maybe database coders are just better at building maintainable code because there is so much at stake?

      With the fork of MySQL into MariaDB, the Open Source community is wresting control back from Oracle. However, it is clear that Oracle’s engineering organisation has a lot to offer MySQL in terms of high scalability knowledge. As you allude to, building scalable code is HARD – there are very few people in the world who can do it. And the OSS community doesn’t have a lot of them around – as should be obvious from benchmarking MySQL, Postgres and Linux. In other words, great database developers are an extremely scarce resource. Having an undergrowth of NoSQL database and forks around ironically make the OSS community LESS able to compete with the big boys. Diversity is not always good.

  6. Javier Guillen   •  

    Interesting article indeed;

    Although I don’t necessarily agree with one of your advice points to MS – kill Tabular models. Aside from being an evolution to the classical OLAP MS framework, I have experienced first hand during consulting engagements how they provide huge business value when user access to data is simplified and enriched with metadata, aside from just being relatively simple to develop. Never mind the whole story around integration with Self-Service BI… There are a number of Power Pivot blogs that are highly popular on search engines and web forums.

    The is the kind of ‘stuff’ that can help bring popularity to a platform…

    Other than that, just a quick spelling correction on the advice section for Oracle – its not Tableuax but Tableau…

    • Thomas Kejser   •     Author

      Javier. I think you are confusing the tabular model with the user interface. The problem with good old analysis services was that the GUI to manage it was horrible – so no business user would ever use it.

      So what did MS do? Instead of fixing the GUI and all the bugs and annoyances it has carried around for 10 years, they “invented” tabular. This got them started on a completely new code base – with all the bugs, annoyances and trouble that comes with it. It also told the entire BI community that MS cannot be trusted with a strategy – everyone who had learned MDX now had to relearn the skills.

      The result? Massive loss in trust and market share as well as some half finished product that still does not have the features or scale of SSAS.

      This is what you get when you have an organisation that tries to “innovate” instead of fixing the problems they have.

      • Doug Lane   •  

        MS never intended for business users to build or maintain multi-dimensional models (Visual Studio is not business user territory), so I don’t think tabular was in response to lousy GUI. Quite the contrary — the GUI isn’t what limits SSAS adoption. The number one problem SSAS has is MDX. It’s a complicated, unintuitive language and there are very, very few people who excel at writing it.

        Like Javier, I believe Microsoft was wise to take the powerful engine of SSAS and open it up to more developers and power users alike by introducing DAX. They will have gained a hundred users for every one MDX expert who threw up their hands and quit SSAS (which I doubt is happening in any significant number). Sure, DAX has a long way to go to catch MDX’s ability, but it’s getting there. But mathematically speaking, making a very powerful BI tool easier to use does not equal a loss of market share.

        • Thomas Kejser   •  

          Doug: Your reply highlights exactly the “cart before the horse” thinking that is so dominant in the SQL Server BI community.

          It is clear (?) that MS never intended SSAS, the same way that they didn’t expect Reporting Services (or SSIS) to be used from inside Visual Studio. But if they didn’t, why didn’t they then implement a tool that WAS intended to be used by non-experts? They didn’t and they let at least 5 years passed where everyone just threw their arms up in the air and said: “well, my end users obviously can’t use this”.

          Instead of thinking about this bleedingly obvious problem from the start (or fixing it when they became aware of it), MS kept using their marketing machine to stuff their confusing message down BI community throats everywhere. When they finally realised they were losing to QlikView and Tableaux, they “invented” a new tool, further fragmenting the market. So now we have a tool that scales and can be used by developers, but not users; and ANOTHER tool that DOESN’T scale and CAN be used by end users and but not for any structured development process. In other words, neither of them solves the BI problem. This is not strategy, it is knee jerk reactions to a market that is running in circles around you.

          Admittedly, MDX was a beast, but so is SQL. The solution is not to invent new languages, it is to put front end tools on top of the data model that ensures that users don’t NEED to write queries and that they can make simple, controlled, modifications to the data. This seems to have worked very well for pretty much every other BI provider than Microsoft – there is plenty of evidence that it can be pulled off. However, the only real front end to MDX (Excel Pivot Tables) had so many bugs and GUI issues that it forced the end user down the path of custom MDX – which I agree is a horrid language. The “solution”: build something new, instead of fixing what you have… Again, this is not strategy.

  7. zibby notsworth   •  

    I get the impression that MS is adjusting SQL Server licensing to match Oracle – I don’t get it. I have used SQL Service since 6.5 and Oracle 11g (Windows) in the last two years. I find SQL Server quicker to deploy configure and get up. Moving an instance to a new server is easier. I find the online SQL Server community to be more approachable with questions. Oracle is monolithic and slower to deploy, move, etc. But my employer uses Oracle Std One which might explain a few things. The Oracle online community in my experience requires a thicker skin. Both of these choices were management decisions. Have only played with MySQL in my spare time. Postgres not at all.

  8. Endrju   •  

    The trouble is, majority of SQL Server questions doesn’t get asked on dba.stackexchange.com, but instead simply on stackoverflow.com (and they don’t get migrated to this other site). Same for PostgreSQL. Don’t know how about MySQL, but I think it can be similar. You would need to account for question tags to have accurate numbers.

    The time to answer SQL Server question on stackoverflow.com is a few minutes typically for most questions. The time to accept answer, however, vary, but that only depends on the question poster.

    • Thomas Kejser   •     Author

      I will grab the data dump from the main stack overflow site and see what it shows when merging it all

  9. Mike West   •  

    Great post Thomas. I love the recommendations section. Bugs be design and MySQL is a toy db kill me.

  10. Bruce   •  

    How about the Oracle community? How should they modify the way they operate?

    • Thomas Kejser   •     Author

      I will type something up soon

  11. Robert L Davis   •  

    All the cool kids are on #sqlhelp on Twitter.

    • Thomas Kejser   •     Author

      Because interesting questions can be answered in a text message?

  12. Nick Craver   •  

    I just wanted to let others know the data is more accessible than the XML dumps for those that want to poke. We host it (via SQL Server, heh) in the Stack Exchange Data Explorer at http://data.stackexchange.com/ which is free for anyone to query. It’s just a far lower barrier of entry to query anything you want. It’s updated every Sunday, where the XML data dumps are quarterly. It includes everything in the XML plus a few more tables and fields. We actually generate the XML dumps from SEDE to ensure they’re the same.

    • Thomas Kejser   •     Author

      Excellent info Nick. Would have saved me a couple of hours to know

  13. Steven Wang   •  

    What a pleasant reading! thanks, Thomas, like the future part so much.

  14. James Lupolt   •  

    PS

    After watching Linux swap out MySQL because a single NUMA node’s memory was full, I must agree that Linux does suck in some areas where Windows does not. This problem was a big pain when I was a MySQL DBA around 2011, and from a recent Google search it still seems to be an active problem with only non-ideal workarounds.

    • Thomas Kejser   •     Author

      Agree James. MySQL and Linux NUMA awareness is in its infancy. I have also found that the Linux scheduler is very poor at picking the best core for a thread to run on. Unlike Windows – it does not seem to understand that preferring L2 cache coherency is often better than being 100% fair. For a high throughput system – this matters a lot

  15. James Lupolt   •  

    Hi Thomas,

    About NoSQL on dba.stackexchange.com, I think the possible exception to your statement is that there is a fair amount of MongoDB activity — it’s the 23rd most-used tag (a bit ahead of DB2) with 390 tag usages and Adam C from MongoDB seems to answer a few questions a month. Other NoSQL databases barely even register like you said, though. For example, Cassandra is the 229th most-used tag and has only been used 35 times.

    I’ve thought about doing some similar mindshare estimates with the data from http://www.itjobswatch.co.uk/ as they seem to have pretty good information about what skills companies in the UK say they’re seeking.

    James

    • Thomas Kejser   •     Author

      James, I would put Db2 in the “barely registers” category too. Would be very interested to see how the job market adds up with SE

  16. tobi   •  

    I think your advice is mostly true. Would you care to extend some advice to Oracle?

    And what’s your opinion on the new SQL Server release cadence, where they release more often but half-finished products (Columnstore indexes in 2012 and Hekaton in 2014 – their best testimonial was an ASP.NET session state provider which is about the simplest scalability challenge there is… Just use Redis for that).

    • Thomas Kejser   •     Author

      Tobi, I think that the columns store feature was crucial (Hekaton, less so). It was the one thing that was missing and a different release cadence might have been required. However – most of the stuff that needs fixing could be done in hot fixes released MUCH more frequently than the current cadence.

    • Thomas Kejser   •     Author

      Tobi, I added Oracle advise. I had to think a bit more about it.

Leave a Reply

Your email address will not be published. Required fields are marked *