Is SQL Server the new Access?

Question

This is a condensed summary of the job market as I've been observing it so far this year and maybe in retrospect last year too.  It may or may not be appropriate to this forum, if you are reading it then so far maybe it has relevance.
But it appears to me as if virtually all new, large-scale work is being moved off of SQL Server and onto cloud and "big data" platforms possibly (but not frequently) including Azure.
What is being left on SQL Server are legacy systems and smaller applications where generalist developers can totally fend for themselves, with the help of a competent DBA platform staff, and just let the power of the hardware overcome any technical
issues.  Most of these apps seem to be whatever fits on a standard version and runs under a VM.  In effect, SQL Server is becoming the new Access!
One additional small attempt at forum relevance: insofar as this market shift might be true, I would attribute it to two engine-related things.  First, the very unfortunate decision by Microsoft that for SQL 2012 licensing for big multicore servers
became far more expensive.  It seems many shops stayed on SQL 2008 for a long time (still!) because of this and have barely looked at SQL 2014.  Second is that frankly SQL Server is not scaling very well beyond the terabyte range without a lot of
high-levels of expertise involved - and especially when cheap management tries to run that multi-terabyte database on 32gb production servers!*  SQL Server's reputation for being easy to use, plug-and-play, may be threatening the success of these larger-scale
apps and is leading to new choices in platform.
Anyone else have any observations along these lines, pro or con?
Thanks,
Josh
*and if you think that's a myth, it is exactly what happened at my last gig, leading to $20,000,000 in development being thrown away - and no, they simply could not be talked into understanding or mitigating the issue.

Answer 1

Josh,
I would think most of this is going to depend on the company, resources, and business models. I added my 2 cents though, enjoy.
But it appears to me as if virtually all new, large-scale work is being moved off of SQL Server and onto cloud and "big data" platforms possibly (but not frequently) including Azure.
I personally don't look at Azure as a big data platform. Currently it has its limits in both processing power and disk IO, has its own issues (such as AD integration, which is possible but takes extra hardware and setup) and has an SLA that you may or may
not be able to live with.
Do I see more things moving Azure - yes, but it's mostly because they are small and is based on cost + expertise. Most of the time there is no in house DBA and it is cheaper to have some other company worry about hosting it, providing the services, hardware,
power, etc. You get redundancy and an out of the box SLA for small applications that are fractions of the cost compared to the licensing + hardware + personnel costs of in-house items.
Remember when everything was run on mainframe, then personal computers came out, now everything is migrating back toward a mainframe feel. It is just how it cycles. "on prem private clouds" are nothing more than beefy hardware with a single purpose all packaged
together (such as offering from HP and Dell) and something a shop of sufficient size can do on their own with enterprise class hardware - again if you have the space and expertise.
What is being left on SQL Server are legacy systems and smaller applications where generalist developers can totally fend for themselves, with the help of a competent DBA platform staff, and just let the power of the hardware overcome any technical
issues. Most of these apps seem to be whatever fits on a standard version and runs under a VM. In effect, SQL Server is becoming the new Access!
This could just be the company that you work for, or someone up higher that hears a key word and latches on. I can tell you that I'm actually in the process of migrating multiple Oracle databases to SQL Server with application upgrades. That isn't counting
the other databases that are currently SQL Server at 1TB+ but it depends on what is considered a small application. To a small company almost all applications are large, versus a large company with 10k+ employees and then anything less than 1k+ users is small.
It also depends on if you're a dev shop or a 3rd party shop. For example, we bought software that runs on a closed source version of MySQL. It happens, that's what they use.
First, the very unfortunate decision by Microsoft that for SQL 2012 licensing for big multicore servers became far more expensive. It seems many shops stayed on SQL 2008 for a long time (still!) because of this and have barely looked at SQL 2014.
Yeah, this made me sad. Following Oracle and IBM was not the way to go, but not our decisions. The interesting thing is, if you read the licensing doc, anything you have with SA can be converted to cores so it isn't a total loss and shouldn't be a reason
to stay at older versions. I still have instances of 2000 running (omfg) that are somehow alive... it's because the software company is no longer around yet we still use that product, not because we don't want to upgrade (read WE as I insist harshly). In fact
I just had an install guide emailed to me about a possible new product and their "supported" version of SQL Server was 2005 SP3, it's all about what they develop on and if they test it on newer versions. Since that takes money most of the time they don't and
it makes me sad with a few drops of angry and then tons of push back until they support something newer.
This is how it will be especially in regulated markets such as stock trading and gambling where products must be "approved" by the boards or commissions before it can be used. I liked to joke that dev shops were 4 years behind, retail and hospitals were
8 years behind and the government still uses pencil and paper.
Second is that frankly SQL Server is not scaling very well beyond the terabyte range without a lot of high-levels of expertise involved - and especially when cheap management tries to run that multi-terabyte database on 32gb production servers!
That is a huge "it depends", I'm not even going to try and lsit the myriad of items that can attribute to this. Very rarely when I am investigating is this an issue to scaling with SQL Server. Most of the time I find two main culprits - the first is a database
design that is terrible and leads to the problems at hand or the other being an application that doesn't properly use the database. When I say properly, I mean HOLDLOCK hints hard coded into application queries and then wondering why concurrency is terrible.
The developers just don't know, understand, or care as their job is to ship a product.
If it makes you feel any better, I have successfully run (for years) a 1+ TB db on a server (2008) with 16 GB of RAM. The database lends itself to the type of workload that doesn't require extremely large datasets in memory and is more of an oltp style with
large and long archives. This is why I say "it depends", because not every database is equal.
Anyone else have any observations along these lines, pro or con?
There will always be a new technology and change in the wind. That's inevitable. Some companies and execs understand this and take caution, some stick to old school (still have AS/400 style batch processing for "real-time" data), some always jump on the
newest thing. YMMV.
I look at it as another tool available to us.
Sean Gallardy | Blog |
Twitter