Voice of the DBA

A few weeks ago, I was at the Small Data SF 2025 Conference in San Francisco. I attended the inaugural event last year and decided to go back again. It's a great chance to hear people thinking about data and its impact on the world in a different way, recognizing that building lager and larger systems isn't always possible. Or a good idea. We might find that smaller systems fit well, especially smaller datasets, which can both serve our purposes and create agility. The manifesto of the conference says that "We champion the power of Small Data and smart AI, believing that less is truly more." There's a bit more, but that's the idea. The format for the conference is a little different, with 3-5 talks in a row, all on one stage, each about 25 minutes long. These are talks with or without slides, but no live demos, just speaking and expressing a point of view. What I found fun was that each person picked their own music to play as they walked onto stage (or ran/danced in the case of Glauber from Turso). It was a bit of fun, with the DJ letting the music play as the person made their way to the front and were welcomed by the audience. I heard rock, metal, hip hop, and more. Read the rest of What's Your Theme Music?

Mary Spender is a musician in the UK who I follow and hope to see live one day. She works hard producing content about music, that business, and, of course, songs. Recently she had a little essay on Instagram where talked about creative time and focus. In it she referenced Elizabeth Gilbert saying "done is better than good." My initial reaction was "that's right." Read the rest of Done is Better than Good

Recently, I had a few questions on database modeling. One was posted in the SQL Server Central forums, and a customer asked about ERD tooling on the same day. This came shortly after Redgate acquired Vertabelo (now Redgate Data Modeler). This stood out to me as very rarely in the last few years have I found people consulting and updating a diagram while performing database development. When I started as a developer and needed to update a database, I had to first update a diagram that was stored in ErWin. We had a dedicated computer (back when we went to an office every day) where the software was run and any developer could us this to update the diagram with proposed changes. Back then, we had to get another peer to sign off on changes before making them, and the peer was supposed to go check the diagram for the change before approving it. That's only if they thought your change made sense and conformed to our standards (naming, design, etc.). Read the rest of Is Data Modeling Common?

SQL Server 2025 was released this week. The announcement came at Ignite and the PASS Data Community Summit with keynotes on Wednesday and Thursday, respectively. While there are some things to look forward to in the release (What's New) and some highlights from T-SQL Tuesday this week, it seems that this release wasn't a very exciting one. On one hand, I blame all the Microsoft Fabric focus, which seems to distract from the core product that powers the databases at many organizations.  The SQL Server blog from Microsoft has had relatively few posts this year, highlighting a few things. The Fabric blog gets more posts, which is something I've seen at Database Weekly as well. As I curate the content during my week, I find a lot more Fabric-focused content than SQL Server-specific posts. That contributes to a lack of excitement for a new version of SQL Server. Read the reset of An Unexciting Exciting Release

I remember a time before email. Some of my first jobs were mostly based on paper being moved from person to person. I'm sure some of you remember these envelopes being used to communicate between individuals in an organization. I used those to send and get memorandums from others before we implemented email. Fortunately, our email implementation (cc:Mail) came soon after I started working in corporations. Initially, people treated email much like paper mail inside organizations. However, over time, people started to treat email differently. It was easy to send an email around other work, so people started to send more messages than they ever would have with paper. They started to dash off notes quickly, sometimes too quickly, as an email might be followed by another email that includes a "I forgot this". As instant messaging grew, we saw similar patterns where people were quick to send messages, regardless of whether they were important, well-thought-out, or even necessary. Read the rest of Don't Create Workslop

Over the last few years, I've worked a lot with various customers on finding better ways to build database software, often using the principles of DevOps to drive the change. A lot of managers and leads want to see a smoother process to help their teams become more efficient. DBAs often want less overhead and friction in the process, while developers just want to deliver code. In many cases, however, what lots of management wants is speed, and they're looking for ways to increase their current speed and deliver more software. Their current rate of development might be quick enough if you can reduce your bottlenecks. Making communication easier, limiting the slowdowns from handoffs, and reducing the risk of mistakes are everyone's goals. However. Read the rest of Being Mindful of Design Time

Imagine that you are about to tackle a new project that will take more than a year. This might be a new system, perhaps a cloud migration, or maybe it's rewriting something that doesn't work well. You don't have enough employees to undertake the project without overloading everyone. Your team needs to grow. Would you rather hire a more senior person from outside the organization or pick a junior person that's already inside your company and teach them what they need to know? Think about this as if you were the one making the decision about the future direction of your software team. Philosophically, do you want to buy experienced people or train/build new ones from your internal staff. Read the rest of Internal Staff Growth

I ran across a thought-provoking post from Chrissy LeMaire asking if we should reconsider SQL Server HA. The post actually asks if you've considered not using it. The default from Chrissy, for most installations, is to use standalone SQL Servers. This isn't to say she's against HA solutions (FCIs or AGs), but that they often cause problems and might not be needed. It's an interesting position to consider. For a long time, I avoided SQL Server clusters as they were hard to setup with a lot of complexity, hardware requirements, etc., and didn't really provide enough benefits over using log shipping with a second server for me.  These days I have clients with mostly AGs, and they seem to run fine. That being said, Chrissy notes that after she left a job, a network outages caused a bunch of downtime. I could see there being downtime, as the old database mirroring (and the it-will-never-die replication) needed a working network. If you have network issues, you better know how to manage your HA technology's issues. Read the rest of Do You Really Need HA?

I wrote recently about some work with Redgate Clone, and one of the things I did was start up a blank container instance of SQL Server from the image named empty-sql-current. This image contains SQL Server 2019. Clearly, "current" was a poor choice. I see this often in various places, where someone will reference "current", "new", "latest", or some other term that denotes the most recent changes. If everyone reading the reference is doing so with knowledge of the past and at a time close to publication, this works fine. However, a year later, does this make sense? At the same time, I do like consistent names that might be used in scripts. If I always want developers pulling the latest item, I might use latest. However, if versions are important, than "latest" or "current" might not be the best choice. Much of the time, I tend to try and get a version or some other specific indicator in a name. Read the rest of Poor Name Choice

I wrote recently about a bad first day for an intern. He/she was fired, without cause in my opinion, when a production database was damaged while following a document for developer setup. The situation felt like a mistake, and one that wasn't necessarily the fault of the individual. To me, this was extremely poor handling of the situation from a CTO. In the discussion for the piece, someone pointed out that it might not just be a new employee who makes a mistake that causes downtime. Certainly, an inexperienced employee could have caused the issue, but I know there are plenty people with lots of time in a position who make similar mistakes. It could be that one who has been there a long time followed a poorly documented procedure for the first time, or applied the procedure to the wrong situation. Often, I find these are relatively simple mistakes because someone isn't as familiar with a protocol or skill as another person assumed they were. Read the rest of Practice Until You Don't Get It Wrong

I ran across this article on a survey about AI usage recently. The headline is this: 55% of businesses admit wrong decisions in making employees redundant when bringing AI into the workforce. That sounds a little ominous for those making these decisions, and a lot of you might be saying, "I could have told you that. Using AI to replace people is a bad decision." On the surface, I agree. I dislike the idea that companies will opt for a semi-competent AI bot or agent to replace people, thereby further exacerbating the challenges faced by many workers in the modern world. Read the rest of The Selfish Case for Learning AI

Cloud costs are high and growing. Some orgs think they're out of control and are trying to limit spend. Some orgs are looking to leave the cloud. A lot of IT spend over the years has been seen as a cost center, with many executives trying to limit the growth or spend, even while they aim for digital transformations of their businesses. Throughout my career, it's been interesting seeing the tension of groups trying to take advantage of technology and the finance departments trying to manage costs. The cloud brings some of the same debates/arguments/concerns to the forefront. Partially because of scale, as we can add cloud resources much quicker than we can with a CapEx purchase. Partially because we've also often lost some control over budgeting with the move to OpEx and subscription things. Read the rest of Reducing Cloud Cost

DevOps can mean a lot of things, but I find in practice that this results in a team using Continuous Integration and Continuous Deployment/Delivery using automation to check and evaluate your software in some way. This should result in quicker delivery of updates and changes to customers, better agility, and higher quality of code. That last one only comes if you use testing and try to ensure your code is well-written. It's easy to just use DevOps to throw out more poorly written code that doesn't perform well. Read the rest of DevOps is DevOps

The other day, I asked my daughter if she wanted me to make her some eggs. She responded with a "Yes!" in text and came to sit up at the counter while I cooked for us both. We chatted a bit, and at one point she said, "Thanks for cooking, but it's not that I can't cook." I laughed a bit and responded with "this isn't a can/can't situation, it's a do/don't or will/won't one." I know my girl can cook; I made sure all my kids learned how to cook. It's that they often choose not to, hunting for leftovers, going for takeout, or skipping meals. Read the rest of Can/Can't Do/Don't

I fly a lot, as you might have guessed if you read my blog regularly. In 2025, I've been on 56 United planes as I write this, with about 10 left to go before the end of the year. One of the things United does is sometimes send out a quick "survey" after a flight, checking to see if everything went smoothly. I don't always fill these out, but recently I decided to give some feedback as I had a great experience. I really wanted to just complement the onboard crew, but the survey was quite a few pages (10?) and a lot of questions. I started to try and fill it out, but lost focus after a few pages. This felt like a chore, and I started to just randomly click some of the selections asking me to rate things 1-10. I wasn't really rating the items; I was trying to get done. Eventually, I bailed on the survey and didn't complete it, but that got me thinking about the data from these surveys. Read the rest of Be Wary of Data

Most of you reading this work in technology, and I assume that you've had to learn something new on the job. Technology is constantly evolving, even on our existing platforms. On top of that, we are regularly given tasks that are outside of our current skill sets. Maybe not far outside, but to meet the changing demands of our jobs, we need to learn new things. I ran across an interesting post (on a new site) from Brent Ozar. I think that guy writes as much as me, but he wrote this one: Why I Started Using Postgres (And You Might Too). It's a little provocative, but there are good posts on the site about things Brent learned in PostgreSQL. I won't go into whether learning PostgreSQL is a good idea. Read the rest of The Journey to PostgreSQL (or anything)

I ran across an interesting open letter. Most of these are from individuals, often complaining or lamenting on the way something in the world works, or maybe doesn't work. This latest letter was from the Chief InfoSec Officer at JPMorganChase, a large worldwide bank. This open letter was written to the software suppliers looking to do business with JPMorganChase, especially those in the SaaS area (Software as a Service). The letter opens by noting that SaaS is enabling cyber attackers and asks for three things: prioritize security over features, modernize security architecture, and work with security collaboratively to prevent abuse of connected systems. Read the rest of We Should Demand Better

I caught a short post from Gary Bargsley on LinkedIn that had this quote: "Many people do not believe this is true. If there isn't a fire to put out, then you are not doing a good job." He included a repost from Shaik Ashraf with that quote and an image that explains better what things a DBA is doing because they aren't always busy. I would say that by busy we think of a DBA as rushed and always trying to fix something that isn't working well. I've certainly walked into operational positions where this was the case. Things weren't working smoothly or breaking regularly. My phone was always ringing, as I moved from crisis to crisis. For some systems, rebooting them regularly was the fix, not because I didn't want to determine a root cause and fix them, but because I had too many other priorities. A reboot at least recompiled plans, cleared caches, and got the system working for a few days. Read the rest of The Improvement Limit

Recently, I got a bill from Azure. That's not an unusual thing for many of you, but for me it was a surprise because it said I was late paying. I've had a number of services running, and I thought at first that I had left something running too long, like a VM. As I checked, most of the things were paused, even the expensive ones like a Synapse workspace. Instead, I found that my free credits were not being applied. Fortunately, I had changed credit cards or I might have been billed for a few months before I noticed. This was a change in how Microsoft managed benefits, which is fine. I opened a support call and someone helped me, but it took several days to get a response. I was slightly worried about the bills, so I decided to audit the things I had running. Read the rest of Cleaning Up the Cloud

I've spent quite a bit of my career as a DBA/sysadmin/Operations person. However, I've had my share of development positions as well. As I work with customers who look to mature their database development to be more like other software development, I've noticed that PRs sometimes don't get handled as smoothly as we might like. In some sense, they are like help desk trouble tickets that never get closed. One of the first things I caution people about is specifying specific reviewers, especially DBAs. There are often DBAs who are the gatekeepers for code, but if we require them to be the only ones to review code before a CI or test process, we really slow things down. This often happens in smaller environments where one DBA wants to avoid anything impacting their job. They want to review everything before it commits. Read the rest of PRs Are Like Trouble Tickets