Voice of the DBA

Category: Editorial

  • Expensive CPUs

    There have been a lot of features added to the SQL Server platform over the years. Several of these features let us perform functions that are beyond what a database has traditionally been designed to handle. SQL Server has had the ability to send emails,  execute Python/R/etc. code, and in SQL Server 2025, we can call REST endpoints.

    Quite a few of these features (arguably) are more application-oriented than database-oriented. There’s nothing inherently wrong with having a server perform some of these functions, and there have been some very creative implementations using these features. I recently ran into one of these examples from Amy Abel, where she shows how to use the new REST endpoint feature to call an AI LLM to generate and send emails from your database server. That’s creative, and it’s reminiscent of the numerous examples from various experts over the years who demonstrate how these features can be used to accomplish a task.

    However, these are examples. They work amazingly well with one user running a limited workload. This reminds me of many of the examples I’ve seen using the AI vector enhancement in SQL Server 2025 to create embeddings from string data using an LLM. That is interesting, but most of the examples show a trigger being used to update the encodings. Imagine users updating data and those triggers firing. Imagine a real workload and how often your users might update string data you want to use in an AI application, especially a RAG application. Think about how complex or long-running triggers in your applications now that can overload your system.

    CPUs in database servers are expensive. The hardware isn’t more expensive, but the software is pricey. Standard Edition is limited to 24 or 32 cores (depending on version), and while Enterprise isn’t limited to any number of cores, the cost of each core is $$$$. Is it worth having those $$$$ cores sending emails or calling external services? Or would you be better offloading those calls to another server, like an app server, where the cost of the core is the hardware and a little .NET code running separately?

    Many of us already struggle with the database server as a bottleneck for our application and workload. Scaling up our database systems is expensive and cumbersome. We struggle to get approval for larger VMs, and if we scale up in the cloud, it gets very expensive very fast. I’m not surprised that database vendors are happy to add these features as it increases the licensing cost for applications using them.

    I know the majority of the cost of building applications is labor and software developers’ time. However, that’s changing with LLMs that can produce code cheaply. I keep seeing that the cost of writing code is approaching zero.

    That’s not going to be true if you use LLMs trained on the example code that increases your database licensing cost. Then the cost might be higher than you expect.

    Steve Jones

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

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

  • 25 Years of SQL Server Central

    The oldest article we have on the site is Tame Those Strings! Part 4 – Numeric Conversions, by me. It’s dated 2001-04-18, though I think that’s a date we picked when we converted all the content from one database to another. The founders agreed sometime during Feb 2001 to jointly run SQL Server Central. Since we each owned the copyright of our articles from another site, we migrated several articles to build up our content library. This was back when Andy, Brian, and I all had full-time jobs and managed the site during breaks, nights, and weekends.

    That was 25 years ago.

    Twenty. Five. Years.

    It’s incredible to think that almost half my life has been spent working with this community. That joint effort morphed into a full-time job for me sometime in late 2003 or 2004. I took a pay cut to run the site, though as we grew from one to two to five to six newsletters a week, we started to make enough money to make up the difference. I was a horrible salesman, but fortunately, we had a great site that kept growing week after week, and we didn’t need to rely on my salesmanship. The site grew from dozens of users when we started to thousands in a few months to tens of thousands in a year. Eventually, we reached a million registered users, which was quite a milestone for us.

    Apart from the site, we published books and gave out copies at our annual party during the PASS Summit. That party was one of the highlights of my year. We also used to publish a magazine in partnership with the PASS organization. That was a stressful time, with me trying to manage an every-other-month schedule for the magazine, which had to be laid out, printed, and shipped to subscribers. While that was going on I had to keep a couple of yearly book projects going and still get daily articles published.

    I started writing these editorials because I was a little bored with the job. I never imagined how popular these pieces would become and how many people would read them. I suppose I should have as I was the one who negotiated and paid for our emailing software. We used to pay for Lyris Listmanager, which cost a few thousand dollars when we started. As we grew, we needed to send more emails overnight. One year I received a quote from Lyris for a few hundred thousand dollars to add the additional sending capacity. When I called the sales rep, he told me the only small companies sending more emails than us were the porn people. Needless to say, Andy took that as a challenge, not wanting to pay hundreds of thousands of dollars for email software.  we designed a system using an SMTP component that would let us send a lot more emails. At our peak, we were sending over 8 million emails a week.

    I had to learn a lot about running this site, from SMTP tricks and the how CAN-SPAM act applies to negotiating advertising contracts with customers. I had to manage hosting locations in the early 2000s. We first rented a VM, but they were too small after about six months. We moved to the house of a friend of mine, where he had 3Mbps broadband connection (this was 2002). At the time, I only had an ISDN connection, which wouldn’t cut it. We migrated through a few different co-location facilities in the Denver area that I had worked with as a corporate employee. Those moves entailed me physically moving servers into cages (or partial cages) in cold rooms, re-configuring our switch and firewall, and ensuring everything connected to the Internet. I even had an account at Dell as we regularly upgraded hardware.

    When we sold the site to Redgate, some of those hassles went away, and I could focus on just being the editor of the site. I no longer had hosting responsibilities or even coding ones. Things were good and bad with that change . Good as I had developers to whom I could send bugs, but bad in that they had other, higher priorities. In the last few years, I’ve struggled to get things enhanced or fixed on the site, though I’ve been promised that is changing this year.

    Despite all the changes over the years, I’m still thrilled to be the editor of SQL Server Central and glad that Redgate continues to run and support the community. Most of my time is spent doing other work with Redgate, but managing this site continues to be a significant portion of my work week.

    And I still enjoy it.

    I want to thank everyone who has read an article, asked or answered a question, syndicated their blog, tried the Question of the Day, written an article, or just left a comment on a piece. This has been an amazing community where many of you learned to be a better data professional. Lots of you asked, debated, and shared your knowledge with others in an extremely neighborly way. It’s been a joy to see this community grow into one where we appreciate, value, and love each other. I’ve made many friends here, met many of you in person, and seen you get a value from this community that cannot be measured. The success of this community is because of all of you.

    I’m blessed to have joined you here for 25 years, and I look forward to many more.

    Steve Jones

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

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

  • There Are a Lot of Databases

    I was reading Andy Pavlo’s end-of-year review of the database world. He’s done this for a number of years, and there are links to previous recaps in the piece. He is an associate computer science professor at Carnegie Mellon University, working on quite a few database-related projects. In the review, he tends to track the database world from the perspective of business success and money. There are certainly parts of it that discuss technical changes, but my overall impression is more about the business and usage success than it is about the way database systems work.

    The main thing that struck me after reading the review was how many database systems there are in the world. I hadn’t heard of any of these: RaptorDB, TigerData, Tembo, StormDB, Translattice, FerretDB, DocDB, SpiralDB, Tantivy, SkySQL, HeavyDB, and more. I’m sure I missed listing some I didn’t recognize, and quite a few of these are PostgreSQL-based systems, but still, that’s a lot of database systems that exist and are having success.

    Last year, I ran into someone who worked at a company that had implemented ArangoDB for the software their company sold. This system had something to do with tracking parts and managing schematics for machines, which is a great place to use a graph database. I asked them why they didn’t pick a more well-known and used graph database like Neo4j. He answered that cost was a big reason, but if Arango failed to wrok, they felt could port their data over to another platform. He did mention that training new people was a challenge, which I believe is a good reason to stick with more mainstream systems. However, I understand that people placing bets on less well-known technologies is how the popularity of those platforms grows.

    As a side note, I keep confusing ArangoDB with AvacadoDB. Maybe because I like guacamole.

    If I look at DB-Engines, I see lots of platforms I recognize and a few I don’t, but overall this is a long list. Some you could argue aren’t really database platforms, but these are platforms people report they are using. There are 429 ranked, which is quite a few. I’m not sure there are that many different models of cars being produced in the US each year.

    Many of these are specialized platforms and might be suitable or even preferred in certain situations. I wonder if any of you reading this are running Hazelcast or Presto. Or anything else unusual. If you are, why? What’s better about one of these systems than the top 5-10 in any category?

    As I look around I realize there are so many databases available to choose from. Perhaps it’s just me, but I prefer choosing from a small list rather than a huge one. Do you feel the same way?

    Steve Jones

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

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

  • More Documentation is Needed

    AI is everywhere, and if you spend any amount of time looking for answers on the Internet to your coding challenges, you’ve likely encountered a lot of poor, average, good, bad, amazing, and just-helpful-enough AI content. For awhile, I was avoiding the AI summary from Google as the quality seemed slightly off, but lately it’s gotten good enough that I tend use it to decide which links to click on in the results. The summary helps me better understand the context Google sees in my search query.

    I ran across a post on coding documentation and how helpful these docs are in onboarding, code reviews, and more. The teams that worked smoothly together often had good docs that helped them function as a cohesive group. At least to some extent. Over time, teams start to depend on tools and lose some of that cohesiveness since they rely more on tools than docs. I agree with the piece that this is a part of the reason many teams don’t really function as teams over time.

    In the age of AI, this becomes more important. These AI agents are smart, but gullible and prone to making inconsistent decisions if you let them. In the piece, there’s a great quote: “When your codebase follows consistent patterns, AI assistants become force multipliers. When it doesn’t, they become chaos amplifiers.” Or as we data people know it, garbage in, garbage out.

    The lack of documentation means a lack of guidance for both humans and AI agents. It’s easy to say AI makes crazy decisions when we feed it our code, but humans do the same thing. I can’t even begin to count the number of weird decisions over structure and naming I’ve seen from other humans when I didn’t provide them guidance. It happens even when I give them standards, but at least then we can have a conversation about attention to detail if there are docs.

    I saw Brent’s predictions for AI database development in 2026, and part of the challenge in getting AI to be helpful is the lack of docs many of us have on schemas. I can’t tell you how often I’ve been asked if Redgate has tools that can doc a schema and decipher what data is being stored. Microsoft spent a billion+ on Purview, and its results in classification are a mixed bag. It’s a hard problem, and a lot of the problem is us. We don’t make good decisions about what to name columns or tables, we’re inconsistent, and we reuse columns as our requirements change, subtly altering the data being stored. Usually, this is an overloading of two types of similar, but different, data into one column. Sometimes it’s just storing whatever we want in a column (or allowing a user to do so).

    I’d like to think that the growth of AI will result in a little more attention being paid to documenting our data stores. I’d hope this results in at least using the extended properties or COMMENT capabilities of the different platforms. I think having better ER diagrams might be a second step, though certainly with some AI assistance to help keep things in sync as we evolve our schemas.

    Documentation is tedious work, and it’s not something humans are good at, or want to, update over time. However, if an AI agent were around to do the work and then let a human check the results, I suspect we might do a better job of keeping things up to date. To me, that’s another place where the AI revolution might benefit us all.

    Steve Jones

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

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