Voice of the DBA

Tag: sql server

  • SQL Server Engineering in Austin

    I was lucky enough to attend SQL Saturday Austin 2025 a little over a week ago in conjunction with some work at the Redgate office. The opening keynote at the event was given by Conor Cunningham, who is an architect at Microsoft and runs the engineering team in Austin for the Data Platform. His talk was very interesting and engaging. This was about half the room below.

    20250503_090655

    I’ll describe the talk, which was great, but I’m probably mis-stating something. Keep in mind I’m writing this a few days later from memory.

    One of the interesting things Conor talked about was the engineering process in Redmond. The main thrust was that they work in 6 month planning cycles. Work gets submitted, voted on, works through groups, and as a result, most of the things approved are related to more revenue in some way.

    Good for Microsoft, not something many of us love.

    In Austin, they tackled things differently. You can see the outline in the image below. Conor hired a few engineers here, usually out of college, and they work on new features. Things that are too small to make the list in Redmond, but this also helps grow/train engineers on how to write production quality code.

    20250503_091036

    What do they work on? He had a few slides, but IS [NOT[ DISTICNT was one. He described this a bit, but the cool thing was a bunch of the SQL 2022 features were from Austin. String_Split with the ordinal, the bit functions, and a bunch more.

    20250503_091842

    Basically all the cool features I appreciated, including DATETRUNC, came from this small team. I am very glad they exist.

    He also delved into the challenges of doing remote work. Building SQL Server is a non trivial procss, and they’ve been working to try and make this easier. They refactor code, they try to break things out so engineers can get quicker feedback, write more tests, etc. to make their software engineering easier.

    20250503_094728

    He also talked about their work with hardware manufacturers and some of the optimizations he’s done with CPU and the ATX instructions to make SQL Server a little faster. For some types of queries, they’ve great improved the speed of internal SQL Server processing.

    It was a great talk and quite entertaining. Hopefully some of you will see it elsewhere, or he’ll do it again in Austin and you can come.

     

  • Is SQL Server Feature Complete?

    I heard Brent Ozar recently talked a bit about the SQL Server platform and its future. He also mentioned that Fabric has distracted the data platform team and it isn’t a great product. I tend to agree, and I see too many bugs, holes, and problems. However at the end of this short snippet, he talks about SQL Server with an interesting comment.

    Is SQL Server feature complete?

    That was Brent’s opinion, which is one that I tend to share. I think that the platform is very feature-complete. There aren’t a lot of things I think I really need in order to choose SQL Server as my database. I wish some functions (FORMAT, MERGE) ran faster, and there are a few items (AGs, replication) that could be easier to work with or were more robust under load. However, overall, SQL Server runs well.

    It’s a good choice, there is mature tooling available to help, it’s well understood, easy to administer for the most part, and there are lots of people that have experience on the platform. There are ample reasons to choose SQL Server as a solid relational database platform.

    At the same time, if the product is feature complete, then that gives PostgreSQL, MySQL, and assorted other platforms a target to aim for and potentially displace workloads at a lower cost. Even if the features aren’t quite the same, a much lower cost can be enticing.

    That ignores the cost, often a very high cost, of switching platforms. However, I do see plenty of people investigating other platforms, not to migrate or move, but for new work. That makes sense, and I suspect that is part of the reason that Microsoft keeps trying to raise the bar with new features. I’d prefer they focus more on stability and performance than new stuff, but I get that doesn’t always sell well.

    Are you happy with SQL Server? Looking elsewhere? Ready to learn a few platform? Let us know today.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • The End of SQL Server 2019

    Well, not really the end. I doubt anyone running SQL Server 2019 is going to stop (or upgrade) just because mainstream support ended. Actually, I wonder how many of you know that SQL Server 2019 passed out of mainstream support on Feb 28, 2025. I do think the 6 or 7 of you running Big Data Clusters likely knew this was the end of any support.

    I saw a report in the Register on this, which includes a survey of which versions are still running. This is from an IT asset firm and matches Brent Ozar’s Population report. 44% of you are running SQL Server 2019, which is the largest percentage. Since there’s an additional 32% of you running versions older than 2019, I’m sure that upgrading isn’t a priority.

    It seems like just a couple of years ago that SQL Server 2019 was released. At the end of February Microsoft ended mainstream support for this version. There will still be security fixes released, but no more cumulative updates. The Register says if you don’t upgrade, you might run into a bug and not get a fix (unless you buy extended support), but that’s never worried me. If I haven’t hit a bug 5 years in (or likely 3-4years after my last upgrade), I’m not too worried. If I run into something it’s likely from new code and I’ll just change the code to work around the issue.

    I do expect to run a database platform for a decade, and I am glad that Microsoft continues to supply security patches for this period. While I certainly want every database firewalled, reducing the attack surface area of known vulnerabilities is good. I also find myself less concerned about the security of older versions. If there is a big security vulnerability discovered in 2017 tomorrow that exists in previous version and I had a 2012 server, I’d just prioritize an upgrade then.

    Upgrades are hard, eat a lot of valuable time, and don’t necessarily provide many benefits. Most applications tend to use basic CRUD features and whatever was available at the time in that version. If I use a tally table to split strings in 2017, I’m unlikely to rewrite that code to use STRING_SPLIT with an ordinal if I upgrade to 2022. That certainly isn’t a selling point for me to upgrade. My boss knows that isn’t something we’d take advantage of in older code.

    I’m not a bleeding edge person, and I wouldn’t push for upgrades. If you want to stay somewhat current with versions and are running 2019, I’d be waiting to test my application on SQL Server 2025 at the end of the year or early 2026. If I were mandated to stay current, I’d still be doing that, not jumping to 2022 right now. However, I do recommend that everyone patch their systems with cumulative updates to ensure their security is up to date. There have been several security patches in the past few years that you should have applied and if you haven’t, this is a reminder to do so soon.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • A Very Cool Benefit in SSMS 21

    I saw a post from Erin that Preview 2 is available. I’d gotten a message when I started SSMS v21 this morning, but got distracted.

    I made a short video showing me getting the update, which is way, way easier and more convenient than it used to be.