The 8 Worst Things Microsoft Ever Did to SQL Server
Last week I wrote about the 6 best things Microsoft ever did to SQL Server, but now we gotta pull up a chair and discuss the stinkers.
To be fair, I excluded anything that’s basically ANSI standard. I’m sorry that you don’t like functions and cursors, but the reality is that Microsoft adds that stuff because they have to. And honestly, I don’t have a problem with, say, functions or cursors – it’s Microsoft’s implementation of them in SQL Server that causes performance problems. They could write the engine in a way that was optimized for ’em – but they didn’t. Anyhoo, moving on.
#8: SQL Server on Linux – in 2016 when this feature was announced, I wrote that it was too little, too late, especially if Microsoft tried to stick with the same expensive licensing strategy, and I joked about the decision process to build it. The work required to pull this off was huge, and could have been spent better on things that people really wanted. About a decade later, the adoption speaks for itself: almost nobody uses this. The only reason this “feature” isn’t higher on the list is that I suspect it’s helpful for cloud providers to manage PaaS databases.
#7: VARDECIMAL – sweet summer child, you probably don’t remember that Microsoft brought this new datatype out in SQL Server 2005 Enterprise Edition Service Pack 2, and then promptly deprecated it in the very next version. This came and went so quickly that I don’t think it caused a ton of harm for end users, but it was a sign of bad product management. Microsoft should have held off until they could release real compression, and they shouldn’t have introduced datatypes in service packs, either – what a nightmare for failovers.
#6: Scalar Function Inlining – this SQL Server 2019 feature was such a great idea, but more ambitious than Microsoft could afford to pull off. They simply didn’t dedicate enough development or testing time to do it right, and the result was a buggy mess. For years, Microsoft has been gradually backing this feature back out, as the support KB article explains. Even the most recent Jan 2025 CU17 for SQL Server 2022 found yet another incorrect results scenario with this feature – 6 years after its release!
#5: SQL Server Notification Services (SSNS) – SSAS, SSIS, and SSRS caught on like wildfire, but Notification Services didn’t enjoy the same destiny. SSNS was supposed to let you push notifications (schedule-based or trigger-based) to emails or SSMS – it was basically AWS SNS, but built into the database server. Now, some of you are going to say, “Brent, how could you put English Query in the list of best things because it was cutting edge at the time, but then turn around and put SSNS in the list of worst things? Wasn’t it a valiant cutting edge attempt too?” The answer is no, handling complex notifications is never a good idea in the database layer. Notifications require things like retries and unsubscription handling, and a database server just has no business handling incoming unsubscription attempts. Anybody who’s ever been deeply involved in customer notifications would have immediately flagged this system as a bad idea.
#4: SQL Mail & Database Mail – right about now, you’re yelling at the screen, “Brent, you can’t say it’s a bad idea – I use this every day!” Yep, see, that’s the problem right there: this unreliable, hard-to-troubleshoot feature never should have been a part of the database server. From the start, SQL Server should have had some kind of API access to Exchange or an SMTP server. If we had that kind of API, then by now, we’d have full Slack & Teams integration for SQL Server error messages – but instead, we’ve got the stagnant, awkward Database Mail. (I thought a lot about adding Agent jobs to this worst-ideas list too, but I wasn’t quite ready to deal with y’all’s feedback about that hot take.)
#3: Calling Java from Stored Procedures – around 2019, Microsoft was putting a lot of effort into machine learning at the database level. Language Extensions would let you call R or Python code from stored procs, and I always got the feeling that they kinda threw Java in there just because they could. (I debated calling language extensions altogether a bad idea, but I think Java in particular is exceedingly bad here.)
#2: Big Data Clusters (BDC) – when it was announced for SQL Server 2019, I summed it up by saying, “It’s like linked servers, but since they don’t perform well, we need to scale out across containers.” A lot of Microsoft people got very angry with me about that summary, but I still stand by it. BDC was a ridiculously over-engineered version of linked servers, and Microsoft killed it in the very next SQL Server version.
And the #1 worst thing Microsoft ever did to SQL Server…
They keep walking away from development tooling and starting over.
- In 2000, we built objects, functions, queries, etc in Query Analyzer.
- 2005: the new SQL Server Management Studio replaced that.
- 2008: Data Dude came out as an extension for Visual Studio, and database development was supposed to move over there.
- 2010: Visual Studio 2010 included the Data Dude features in some (but not all) editions.
- 2012-2017: a time of absolute chaos. There was an avalanche of different tooling for different versions of SQL Server, SSIS, Visual Studio, etc with names like “Microsoft SQL Server Data Tools – Business Intelligence for Visual Studio 2013”. The documentation includes this amusing confession: “Historically, the Visual Studio shell used to create SQL Server content types has been released under various names, including SQL Server Data Tools, SQL Server Data Tools – Business Intelligence, and Business Intelligence Development Studio.” The word “historically” is doing a lot of heavy lifting there – those products cycled through across the span of just a few years.
- 2018: the new Azure Data Studio was touted as the new home for database development – not just on Windows, and not just for SQL Server, but for people using Macs, Linux, MySQL, Postgres, CosmosDB, topping their desserts, and mopping their floors.
- And last week, Microsoft stuck a fork in Azure Data Studio, replacing it with the mssql extension in Visual Studio Code.
If you want developers to use your database, you need a consistent development tool. It’s hard for me to overemphasize how important that is. Microsoft’s constant self-destruction of the development tooling has lead to some really sad truths for the year 2025.
For example, Microsoft’s source control for databases & server config hasn’t taken a step forward in 25 years. The rest of the world has moved on – not just for the data itself, but also server settings, even all the way to things like text-file-driven cloud architectures. Oh sure, third parties like Redgate have tried to duct tape things together, but I feel bad for how much money and time they must have spent on it only to have the development environment keep moving around like some kind of Whack-a-Mole game.
That’s just one example of the problems Microsoft’s short attention span has caused – and there are many others. Educational materials can’t keep up. Online blog posts and tutorials refer to dead tooling, and the authors can’t be bothered to redo their work for Microsoft’s tool-du-jour. Community members have a hard time getting behind the new shiny thing because Microsoft has such a piss-poor track record of abandoning their development projects. (I tried hard to embrace Azure Data Studio, complete with writing blog posts that featured SQL notebooks, but gave up when Microsoft couldn’t get execution plans to work in them.)
So now in February 2025, we’re supposed to redirect our efforts to the mssql extension for Visual Studio Code. I salute those of you out there brave enough to dedicate your time to learning how to use that, adding issues to the list, and making it better in the hopes that Microsoft sticks with this plan. I say that from afar, though, because I ain’t joining you on that journey. SSDT and Azure Data Studio burned me badly enough that I’m going to stick with SQL Server Management Studio for as long as it’s available.
When I look at this list of worsts, I take a long, heavy sigh, thinking about how much planning, coding, support, and marketing work went into them. I feel bad for my friends at Microsoft who had hopes and dreams that these turkeys could fly.
But ending on a bright note: when I look at what’s new in SQL Server 2025, and I feel pretty good. I don’t think there’s anything in there that will go down as a major stinker. I don’t think the vector stuff or Fabric mirroring are going to go down as best-features-ever, by any means, but I don’t think they’re as awkward as the stuff in the list above.
71 Comments. Leave new
[…] up, we’ll revisit this topic again, but talk through the worst things Microsoft ever did to SQL Server. Buckle […]
Way back when in the Notification Services days, I was a contractor in MS SQL Support. I was THE person that supported it. Only because I had THE book. The only book. It was horrible. A large company whose name you know was an early adopter and they called in every week.
Also – Auto Shrink.
HAHAHA, the only book, wow…
You have a theme to a number of these…”the database engine should do one thing and do it well.” (5,4, and 3). Add to that list Broker Service. I can’t think of anything worse than adding queuing to a database. And then the implementation just sucked. “Fire and forget” would be a great pattern to do simple things like calling sprocs async (instead of using janky sqlagent jobs) …but SSBS didn’t even support fire and forget. Yuk.
The tooling point (Number 1) is kinda true. There should’ve been one tool…period, instead of these half-assed implementations where “I can use ADS for most things, but still need SSMS for others.” Frankly the worst thing they did with ADS was fork it from vscode. Just build extensions everyone can use. Seems like a no-brainer. I attribute all of this to “we’re database people, we need our own tools, our own queuing, our own way to send email” etc.
#8…some of your arguments may not actually understand the history of why that came about. Suffice it to say a lot of the codebase was still sybase on unix and SQLOS was always a real abstraction so this wasn’t as much of an effort as many think (I work for Microsoft, I somewhat know this to be accurate). What you may not know is many of the choices in the last 10 years around microsoft products/tools moving toward linux (.net, wsl) has to do mostly with “windows runs hotter” (ie, you get better _server density_ on linux) which means it’s cheaper to run as an Azure PaaS product. This is the real issue…if azure is mostly linux for whatever reason, we need to assimilate.
The other decision point that is rarely talked about is…for decades people would say “Oracle is enterprise and SQL Server is for workgroup loads.” I’m sure you’ve heard this. This is rubbish….kinda. What folks really were concerned about was “Windows is for workgroup loads and not enterprise.” Big companies/data centers had processes in place to support nix-like OSs so when Linux actually became enterprise-class (I’d say 1999ish) is was still terribly lacking features vs windows…but it was much more stable and it fit nicely into existing processes that were built around zOS, ultrix, solaris, etc. Microsoft never understood this…the problem wasn’t sql server, the problem was windows. When they saw it for themselves (with azure) they realized, “Oh yeah, we can actually fix this without much effort.”
but yeah…prolly too little too late.
Thanks! About #8 and the history – yeah, I agree and I mentioned it in there that it makes sense for cloud providers. For everybody else, though, I look at the complete lack of supportability there, and wince.
I have really mixed feelings about “the database engine should do one thing and do it well” – after all, I put SSAS/SSIS/SSRS in the list of best-things-MS-did. I think it can make sense to bundle separate apps in the same box for pricing & adoption purposes, but the engine itself should remain separate.
>the database engine should do one thing and do it well” – after all, I put SSAS/SSIS/SSRS in the list of best-things-MS-did…but the engine itself should remain separate.
Spot on. Service Broker was integrated in, which is where I draw the line. But that’s me. And it just sucks. Full stop.
I think it’s important for SQL Server folks to understand Microsoft’s mentality on the “do one thing and do it well.” sqlagent not being a part of azure sql db is beyond obnoxious…but it makes sense given the thought process. If you need to schedule something, go use a scheduler, don’t use something baked into sql server that only the DBA knows about and no one else. And yeah…I can definitely see the counter arguments and can’t disagree with them.
>it makes sense for cloud providers. For everybody else, though, I look at the complete lack of supportability there, and wince.
Can you give an example of the supportability?
I really love sql-on-linux…not because it runs on linux and I despise windows…but rather because that is the stepping stone to containerized sql which is what really matters. (Please, nobody tell me about _windows containers_ …they’re a bloated nightmare and don’t really follow true containerization paradigms). Being able to run sql in a container simplifies development and simplifies deployments onto k8s where I don’t have the rest of my stack (.net, redis, etc) running in containers but now I have this other data persistence mechanism that runs somewhere else with different rules and lifecycles (azure sql db). And certainly I’m not suggesting running a big ol multi-TB enterprise sql server in a container…but containers work for most smaller apps.
About the supportability – try to find people with SQL Server on Linux skills, try to open a support case on it, try to find good documentation on failover & clustering, etc, etc.
Yep. All good points.
I guess I don’t consider SSoL as a replacement for SSoW…but yeah…others do. Big mistake.
Eh, in 1999 Windows was still the third version of Windows ever and SQL server really wasn’t a compelling enterprise DBMS until SQL 2005. By that time, most OS issues in Windows were user issues – especially true if it was deployed on Server 2008.
The ~2005-2015 time period were dark days for systems administration with bad ritualistic practices – such as virtualizing server 2003 at all (never supported by MS, and while it mostly performed well, high resource applications like SQL and Exchange received no shortage of gotchas), disabling UAC, Stopping the windows firewall service, surfing the web on the SQL server, doing development on the SQL server, not reading vmware documentation, NOT patching SQL Server just because, using crash consistent backups (which can corrupt a database if the i/o freeze hits the wrong way), ad nauseum.
I disagree about SQL Server on Linux.
It enables you to run it on Docker and Kubernetes.
That’s why it’s an important and useful feature.
So you’re telling me Windows can’t run in Docker containers? Think hard before you answer that one, blabla….
Windows kind of runs in docker, depending what you are trying to do. SQL Server, thus far, is not one of those things you can successfully try to do in Docker on Windows.
SQL Server on Linux in Docker containers meant that for at least the Intel Mac era it was possible to have devs using Macs work with SQL Server. Azure Data Studio fit the same market. Yes you can run SQL Server in a Windows Docker Container but this is a hard sell for that audience which includes technical decision makers. If you think of SQL Server on Linux as a marketing move, it makes a lot more sense. It means SQL Server is just as easy to reach for as Postgres.
Yes, especially now that Microsoft made SQL Server licensing free.
Wait – one moment please… (listens to earpiece) Hang on, I’m being told… SQL Server Standard Edition is still $2,000 per core, and Enterprise Edition is $7,000 per core, and Postgres is… (listens to earpiece) whoa, that can’t be right, Steve Ognibene told me that it was just as easy to reach for as Postgres!
WINK WINK
Look at this in the context of modernizing a legacy product; not a green field project. A lot of times, removing SQL Server out of the equation is the last thing. Breaking the monolith into discrete parts comes first. So while that is happening, we still need SQL Server to co-exist. So being able to run it in a container is a god send.
So to make sure I understand correctly, you think that Microsoft making it easier to *remove* SQL Server is a good focus for their limited development efforts?
Interesting.
Can’t run both Windows and Linux containers at the same time. If I am working on a distributed application for example, I might need to run Dapr, Redis, Kafka, SQL Server etc. all at one. In such a situation all the containers I need are published in Docker Hub. With Windows, I will have to build my own containers and orchestrate them.
Going to be brutally honest here: if you’re building a distributed application with Dapr, Redis, and Kafka, you shouldn’t be using SQL Server. That just doesn’t make sense.
That’s like saying, “I need to be able to use a hammer, screwdriver, pliers, and a machine gun all at the same time.” One of those things is not like the other, and while they each make sense individually, they don’t make sense as a group.
IMO SQL on Linux and thus the ability to work in Kubernetes was about Azure PaaS services rather than “box product” customers.
Disagree on containerization of databases fully – for production workloads.
Some workloads may be fine, but where do you draw the line?
The tendency for containers to randomly incur massive storage latency of tens of thousands of milliseconds is a problem for a workload that generally should never hit even 100ms. Even if it is rare.
Health detection and awareness is also severely lacking. Something like a pegged CPU is bad in a database server, but a great way to make a situation worse is to blindly kill the node it is pegged in and start rolling back transactions because the node was ‘unhealthy.’
Sure, some of the issues can be configured out of, but someone actually has to do it.
I would like to add sp_OACreate to this list… nowadays people will use CLR for this… but I still see sp_OACreate being used (called from a trigger if you have to ask 🙂 )
Also having BULK INSERT bot not BULK Export and people having to resort to bcp from a command line or .
xp_cmdshell and bcp command
Oh man, I forget about sp_OACreate. Thankfully I don’t see it too often. But it does remind me of something that I should have added: the ability to easily import & export data, like with CSV formats.
Good list, Brent! Adding as an honorable mention in this list: Microsoft’s abandonment of Data Quality Services. The initial release was a bit rough around the edges, but I thought it had a lot of potential and a long future in the SQL Server ecosystem. However, it was never really improved upon after that initial release, and has mostly died on the vine since then.
Thanks! Yeah, I always tell folks when Microsoft brings a data product out, wait til v2 before giving thought to adoption. There have been just way too many one-and-done data products that died on the vine.
I recently worked with SQL Server Database Project in VS2022, and it surprisingly worked very well. I think it has existed quite a long time on the market. It covers all types of source control, branches, schema compare etc.. and for used tasks(we designed a DW with around 200 tables and 500 Stored procedures) it looked like a solid product.
Yes, you need a VS license for it, but you are not sure why you are unhappy with the functionality.
Here is link https://visualstudio.microsoft.com/vs/features/ssdt/
I have not tried VS Code, but it is probably not so usable, Azure Data Studio was crap
Denis – it doesn’t work on Macs. Azure Data Studio does, and that’s one of the many reasons MS was pushing ADS as the future of database development.
I don’t think they compete.
VS Code is just a text editor with advanced functions, VS is a full IDE. For a complex project, the choice is quite obvious, I don’t think MS pushes the usage(VS code vs VS), they just made for different scenarios(e.g. you can’t have a visual designer in VS Code). Not sure about Mac
Denis – go here: https://www.microsoft.com/en-us/sql-server/developer-tools And scroll down to the section titled “Development Tools.” What you see there may open your eyes about what Microsoft pushes, and they do indeed push.
But there is a Visual Studio on this link(but on the second page as a last tile :)_. Probably a complex Enterprise development is not that everyone is needed (and VS Ent price tag is around 2k per year, so it is pretty expensive), they just can’t put it on the first page,
But you can’t say MS is not covering development tooling. You probably may reprise it to “not covering development tooling that available for free”
At this point it feels like you’re just ignoring what I say, so I’ll step aside here and let you go on with your day. Cheers!
>you can’t have a visual designer in VS Code
Sure you can. PromptFlow is one. ipynb’s are another.
>For a complex project, the choice is quite obvious
I agree…use vscode. hahaha. Seriously, it’s OSS, based on electron (javascript on the desktop…ie, it runs anywhere like a mac, xfce4), and all the latest tooling around almost everything has a vscode extension long before a vs equivalent. And devcontainers…wow…these things are a godsend. vs still doesn’t support them.
The full VS typically lags behind. For example, support for the Fabric SQL DB is lacking imo.
Ironically, ADS was the only tool where I could get a deployment working to Fabric SQL DB…
Can’t really argue with any of those too much. I think there’s more value to SQL on Linux that isn’t seen by those of us on the front lines, but I’ve encountered a couple of clients who don’t want to pay for the Windows license, but will pay for the SQL license. As you noted – more for the cloud in most cases and I suspect it’s behind a lot of the Azure functionality in various forms. That containerization for the base bits can make it really easy to “swap” the version for the database without a lot of effort so … there’s value.
I have to agree on the DB Project side. It’s not a _bad_ product, but the inconsistency over the years and the evolution has not made it too friendly. That’s not even mentioning the fun of working with things outside of the current database (system databases, linked servers, cross-db work, etc). That all works – but is more convoluted than it should be. It’s also not too great at handling databases with large numbers of objects. But I’ll admit I like a lot of things about that “state-based” dev model as opposed to the “migrations” model.
I’ll add another vote for “Service Broker”. Lots of potential, but it was never really supported and if something went sideways it was _really_ hard to troubleshoot.
>I’ve encountered a couple of clients who don’t want to pay for the Windows license, but will pay for the SQL license
…which was one of my points. Orgs have never had a problem _per se_ with SQL Server, it was always windows. Patching, the lack of scripting, the bloat. Add to that the licensing. I forget the deets but it was around the 2008 releases where microsoft changed to per-core from per-socket licensing and SQL you bought in like multiples of 4 and Windows you had to buy in like multiples of 6 so there was this huge mismatch which was confusing and infuriating. I don’t remember the exact details…trying to forget them frankly.
I was just reliving horrors from the past 35 years of my career and maybe a Number 9 for your list…FILESTREAM.
Ugh.
Another case where too much was shoehorned into core SQL Server.
we are using FILESTREAM and it works very well – if you create your own functions / procedures.
E.g. I can move 20k files from one folder into another one within 10 seconds – try this with the Windows Explorer or cmd. Same for DELETE or DIR, where you could treat the FILESTREAM as a usual SQL database.
Theoretical I could even use something as DECOMPRESS() onto the varbinary column of a *.csv.gz and then use STRING_SPLIT etc. to parse it (or XML/JSON functions), but this isn’t anything that I did besides some performance tests for a special case.
Of course you could always argue, that files belongs not into the database but onto a separate file server, but this is a whole other point and buisness / design decicions made years before tends to stick :-).
PS: the documentation says, that there should not be more than ~32k (?) files in a folder, but I already had a folder with > 400k files without any problems
May I also suggest an honorable mention for Stretch Database? IMO, it could have been really useful, if it wasn’t so horrifically overpriced. Another “we hardly knew ya…”
It was a mistake in my opinion to remove SQL debugger. I find having to jump over to Visual Studio to debug a pain in the rear.
Not only that, but I work remotely on a lot of customer’s databases. Visual Studio is a big install, even the community edition, and it’s not available remotely on the servers/systems I have to access. In trying to connect from my desktop to the remote SQL instances, it can be very challenging to set up. There are firewall rules and other security barriers that make it pretty impractical to use. I sometimes just have to install SQL MS 2017 on a remote desktop to get the job done. I’m sure that will stop working someday as well.
Yep this,
Erin is wrong, Plain and simple.
since VS 2022 has a debugger built-in, no excuses
Easily trade for Dark Mode
Charging hosting providers, such as AWS, an arm and a leg for SQL Server licenses, resulting in significantly higher prices than Sql Server in Azure. In my mind this is a bad and anti-competitive practice. On top of that it forces MS’s loyal customers to invest to get off SQL Server. Loose-loose proposition.
” I feel bad for my friends at Microsoft who had hopes and dreams that these turkeys could fly.”
“As God as my witness, I thought turkeys could fly.” Arthur Carlson – Owner, KWRP radio Cincinnati Ohio
That’s WKRP – it’s east of the Mississipi River.
https://www.youtube.com/watch?v=BGFtV6-ALoQ
“The desire to retire Azure Data Studio was to simplify and enhance the SQL development experience”
Devs feelin enhanced yet? At least simple enough? No? Hmm
The one that breaks my heart is in-memory oltp.
There was a focus shift away from it along the way and I felt it was really close to being useful (for us). It’s almost like teasing.
It’s true! I had another list of things that were polarizing, but not necessarily best-of or worst-of. In-Memory OLTP, Service Broker, XML/JSON/NoSQL, spatial, in-memory analytics…
I didn’t end up writing that blog post just because I ran out of time, and I couldn’t think of a good packaging format for it. I thought about calling it “features that didn’t get enough development” or “features that almost made the big time.”
Top 8 Things Microsoft Neglected in SQL Server
Spatial is a bit complicated but works well (enough), if you take the time to learn it and understand the problem / solution.
I solved a problem to assigne millions of gps points to other points with SQL in ~1:20 h runtime while his Phyton script runs for > 1 day.
So I’d say it has its use, even if it has to call external DLLs and is a bit slow for this reason.
A few things:
1) Turkeys sleep in trees!
2) I don’t know what I’d do without SQL Agent Jobs
3) MS originally closed the support ticket when that scalar inline bug was initially reported. We had to ask them to reopen the case, and even then it took a few months to convince the folks at MS that, in fact, getting the wrong data back from your query is a bad thing ™. That bug was reported 14 months ago.
Interesting post and comments. #8 is strictly for MS. Maybe it helps other cloud providers, but anyone that wants to give a CRUD, simple DB for an app that actually has decent backup/recovery wants SSoL. Patially licensing, but really it’s lower resource usage on the host. Windows is just a bit heavy. I’m sure there are xx% less CPUs in Azure because they run that PaaS stuff on Linux.
I will say I tend to stick inside core T-SQL/CRUD stuff and SSoL in a container works well.
The others, they’re all a mess. I always wondered back in the SQL 6.5 days as I struggled with a #$@#$%$%$ mail profile in Windows why I couldn’t just auth to an SMTP server easily from a config file.
The rest, I might add in spatial as they had great plans (from Isaac in the early 2000s), but never invested further. I might also add a lack of investment in a more robust replication engine and tooling is a huge loss. It’s amazing, but brittle. When it works, I love it. When it doesn’t, I want to punch an engineer in the throat.
I totally agree with the development tools problem. I don’t know how much time I’ve spent trying to figure out what I need to open an SSIS project in Visual Studio. You would think checking Data Tools during install would be enough but alas, it is not. I’m principally a Mac user so doing it all in a VM on my Mac adds another complexity. Now that Macs are ARM chipsets only adds to the frustration.
>Disagree on containerization of databases fully – for production workloads.
I disagree with almost all of this. Maybe 5ish years ago there were very good reasons why containerization of ANY application that relied on _persisted state_ (not just databases) was a poor idea. State management in containerized applications was immature. That’s just not the case today. k8s PVs and PVCs now work much better with various disk and object stores.
Pragmatically, a _container_ is nothing more than another layer of abstraction, no different than a VM or a SAN. Things have gotten better and …
>where do you draw the line?
…can’t you make the same argument with VMs and SANs? There are mosdef workloads where it’s just that critical that a VM maybe isn’t good enough and bare metal is needed. Or a SAN won’t work and I need fusion io.
>containers to randomly incur massive storage latency of tens of thousands of milliseconds
this isn’t the fault of the container or the code, rather a fault of misconfigured storage. No different than a SAN.
>State management in containerized applications was immature. That’s just not the case today.
Persistence is a trivial consideration. Doing silly things like not killing a node because it was ‘unhealthy,’ needed to scale, needed to be moved, a host needed to be maintained. On something like a file server or blob storage when these events happen, 99% of the time it is fine, and 1% of the time it requires a helpdesk ticket to remove a corrupted file, a ‘stuck’ open file handle, whatever. On a database instance this can result in an outage or data corruption. It is not coincidental that AWS does not use containers to host aurora or RDS and that MS specifically tells you not to use the container based general purpose database sku for production workloads; Or that if you choose to do so anyways, when you open a ticket to question the reliability issues it creates, they tell you that you should not be using the container-based general purpose sku.
>…can’t you make the same argument with VMs and SANs?
No, because the performance requirements are easily quantifiable and predictable.
>this isn’t the fault of the container or the code, rather a fault of misconfigured storage. No different than a SAN.
This is only true if it is actually the performance of the storage that is the problem. And not because a node was rebalanced to a node with low CPU but high interrupts (in an endless chain of storage i/o bugs in docker and kubernetes), or its configured to only use the storage HBAs directly attached to the local CPU, but the storage network on the HBA on that socket is saturated, or its configured to use any HBA on the host and it decides to use an HBA attached to another CPU, Or because it doesn’t multipath correctly because It was implemented using NFSv3 with no boxed directory support to implement NFSv4 (to be fair this is an issue for vmware as well, but somehow they seem to fake multipath io well enough even in esxi 4.x) etc
The beauty of Query Analyzer was no longer loosing my scripts every time Enterprise Manager crashed. SSMS still crashes regularly, but at least we have auto-save now.
Aargh, now I just got adjusted exporting data to CSV /JSON / Excel with Azure data studio. SSMS was too troublesome for that.
Data tools SSIS not getting a lot of love, depends on VS version, regular crashes
Also SSRS and SSAS kinda got abandoned when the push to the cloud started ( data factory / powerbi )
SQL Server Extended events management
Most annoying in the daily work:
I can start an SQL Agent job from step 10 but can’t say to execute just this step or just run step 10 – 13 (yes, we have some long jobs that usually do some small imports each after the other and don’t want to bload the Job list by adding tons of mini jobs)
So I always have to edit the job, set the designited end job to “Quit with success”, run the job and hope that I don’t forget to set it back after I’m done with my tests / bugfixes or whatever I’m supposed to do.
And of course the security implementation of SQL Agent Jobs. It can only have one owner who is a single user (not a group / server role / db role). And besides this user only SysAdmins may modify this job. And often it is set to SysAdmin, which means, that everything that runs inside this job has SA privilegues.
So if you don’t want every developer to by SysAdmin, only the creator of the job (= default owner) would be able to modfiy it (no sick or vacation leave for the next few years).
Or you create one or more SQL logins which is/are used to own this job and gets the needed permissions to do their work. And then give the credentials to every developer who needs to modify the job (e.g. to run just one or two of the steps) and hope that no auditor want’s ever some sort of protocol who modified a job, because all devs of a teams have to share the same SQL user (otherwise they could not fix / modify jobs created by someone else).
[…] The 8 Worst Things Microsoft Ever Did to SQL Server (Brent Ozar) […]
Allowing for ODBC functions in TSQL !
( New Dev(s), new challenges )
Geez, the idea of one universal API for notifications is soo good, it’s practically lies on the surface, yet looks so genius. And what about SQL server jobs? Well, they aren’t perfect, but not so bad at all, at least better that windows task scheduler. Yet, i think that this tool is stagnating as well – no big improvements since SQL Server 2008. Sometimes i notice that it lacks some functionality here and there, some features that just asking for themselves to be implemented.
Hi Brent. Thanks for what you do on these types of things. Much appreciated, good Sir!
On #6 (Scalar Function Inlining), you wrote…
“For years, Microsoft has been gradually backing this feature back out, as the support KB article explains.”
I see a lot of fixes in that KB but I’m not sure any of it implies that “Microsoft has been gradually backing this feature back out”. What in that article makes you say so?
My pleasure! When you read the KB article, pay close attention to the line “This cumulative update also blocks inlining in the following scenarios:” – everything below that line was NOT fixed. Just the opposite – Microsoft simply turned off function inlining in that growing list of scenarios.
Got it and, if it were a snake, it would have bit me. 🙂 Thanks, Brent.
Hahaha, you’re always welcome, sir!
I so love the take on Microsoft and their repeated practice of abandoning tools and features. I 100% agree, don’t start using something and invest time and effort into it until you are sure MS will do the same.
But I have to say, abandoning RDS really annoys me. The SQL Server extension for VS code is “Not ready for prime time” by any stretch of the imagination and many other useful extensions for RDS are not available in VS Code. As someone who’s daily driver computer is Linux This just doesn’t cut it yet. We shall see if MS makes the effort to fix the MSSQL extension and port the other extensions over to VS Code.
For me, RDS has been a great tool to use so I don’t have to log into the Windows Virtual Desktop just to write or modify t-SQL.
I sometimes have this paranoid feeling that Microsoft hates me, I’m glad I’m not alone in this.
Idea for a new blog post – 8 great things Microsoft *should* do to SQL Server.
Great idea except it would be a battle of which 8 things would be the most helpful. The needy come in various forms.
Remembering connect.microsoft.com and looking at the current user voice site, it would be more of 800 important things they should improve/implement rather than just 8.
Yap the SSMS is getting worst every release but the stupidiest thing is the need for a restart of the server after installing it.
I’m haven’t fully accepted that Azure Data Studio is no longer a thing. I liked it because I didn’t need Admin privileges to install. So when I was supporting another computer in place, I could whip open Azure and work on stuff while waiting for something on the client computer to do stuff.
About of a controversial one, my vote is for Full Text Indexing. This promised amazing functionality, but it never scaled. I remember asking my MD for a budget for 10 servers, each with a copy of the db on in an attempt to scale. His reaction said it all. We eventually moved to Elastic on one server and never looked back.
SQL Linux I feel was a really, really, teally expensive tick box to make life easier for the marketing and sales people.
Personally I would put email much higher on the list. Maybe #2.