Voice of the DBA

Author: way0utwest

  • The New World Of AI Robots

    It’s been a good time for robots. While on vacation last week I caught this video of a robot running. It’s impressive for a bit, and then it devolves into the inspiration for lots humorous comments as it crashes into a wall. There are some funny comments, but some pedantic ones that note the robot can’t beat a human record because it’s not a human.

    That’s correct, but …

    The comments miss the point. The robot will improve it’s capabilities, and much faster than a human can. The AI/ML advances of the last few years mean that we don’t have to program robots to be precise and exact. The fact that a robot can balance and run and stay inside the lanes is incredible. I suspect these robots, both humanoid and other form factors will start to become more commonplace in our world.

    Which is scary.

    Not for us tech people, though certainly AI advances are worrisome. More, I worry about other jobs. Think about the industrial robots of the last 30 years that have been used in places like car manufacturing. They are bespoke, designed to do certain jobs, and in a certain way. They are programmed with fairly tight tolerances to perform a specific task, often at a quicker and more reliable (and repeatable) way than a human can. There were plenty of false starts here, but today many robots are used alongside humans to assemble cars. You can see them working here, doing tasks that would be slower and harder for humans, even with mechanical aids.

    There is talk of humanoid robots being used in place of some humans, reducing the slow and complex setup . This also lets the robots work in the same places and spaces, moving the same way, as humans do. This might reduce some of the labor costs in the future. That might not seem like a big change overall, as lots of manufacturing uses automation in some way today, but think past this.

    You can purchase a humanoid robot for under $5000. That might not be very capable now, but as LLMs get more capable and perhaps specialized models for different purposes like image recognition, this is an issue. Imagine you own an oil change business. You pay 5 people to do most of the work on cars. Those people likely cost you $2000-2500 a month each. That’s the cost of 2 robots, without the hassles of hiring, termination, breaks, etc. An AI LLM can already identify items from a camera image. Is it a far stretch to think that a robot could identify the oil drain plug and the oil filter on a car by moving around it? How hard would it be for a robot to grab a human ratchet, pick the right socket after a database lookup, and remove the plug. They could tell when the oil finished draining and then replace the plug, tightening it to the correct torque. And being a robot, they might do this without forgetting to position the drain or replace the plug.

    In my mind, a $5k robot quickly becomes capable of a lot of human jobs. There might still be the need for some humans, but we might easily replace 50%+ of them in a lot of common jobs. Stocking shelves, acting as cashiers, who knows what else these AI driven systems might accomplish. That’s truly a scary world, where human labor in many cases might be devalued.

    In the software world, it seems the people having the most success have the best judgment. People who are above average software engineers get above average results from LLMs, and I suspect this will be the case for a long time. Very average, or worse, engineers get worse results and I think are the source of many of the stories of AI coding failures.

    I don’t know what a lot of manual labor jobs will do when management starts to experiment with robots, but I know that in our world you can compete and succeed against AI coding agents by learning to work with them, apply your judgment and use them as tools that make you more effective.

    Steve Jones

  • An Eventual Consistency Scam

    Recently I sold a car. It was an interesting process as I hadn’t sold a car to someone I didn’t know in a long time. I listed the car in a few places and was surprised by the interest. It was an EV (I guess it still is), and with the rising price of fuel in the US, maybe I shouldn’t have been surprised. I arranged a couple of showings, but I had quite a few people offer to buy the car after only seeing a few pictures, asking if I’d take a check.

    Some of you might be wary at this point, and I was. However, my wife had gotten similar offers from a few people when she was selling a horse. She never did, but we talked about where the scam is if someone sends a check and says they’ll wait for the funds to clear. This piece decodes where it is.

    I was curious, so I agreed to take checks from three people. Two of them sent the checks in registered letters, with proof of delivery. This is a USD$20 cost right now. One sent a FedEx letter. That probably cost a similar amount. In all cases, the people said they were sending enough for the car to be shipped, on top of my asking price. I also told them I’d need the check to clear, and they agreed.

    The first one I received, I drove by the bank while in town and deposited the check. I discussed the check clearing with the bank. I was told by the teller that I’d be able to get $400 that day and the rest the next day. I asked about when the check actually clears and the funds were moved, since all three checks were drawn on non-Colorado banks. The teller realized I wanted validation and said it would be 7-10 days and gave me a customer service number to call to check when funds were actually moved

    I haven’t used checks very much the last few years. While I know technology has improved, what has mostly happened is that the banks operate on a system of trust that appears to move faster even though many of the underlying systems are older and still slow. When you deposit a check, the bank doesn’t validate anything. That might seem strange, but it doesn’t. It sends the bank routing number, the account number, and amount through a process that reconciles the money with another bank.

    Think of this as data in two different databases, which it really is. The update in bank 1 isn’t sent to bank 2 for a period of time. The update from bank 2, which debits their account and credits bank 1, takes longer. In this case, the time is in days.

    That’s serious eventual consistency.

    What happened with person 1 was that they asked for confirmation of the deposit, and then texted me 2 days later saying that they’d need a deposit for the shipping company. I repeated that I’d need the funds to clear. They wanted to argue about needing to move fast, but I ignored them. After a few days, they said they were sick and could I front them money for a few bills and they’d drive to get the car. I didn’t agree and eventually they gave up communicating with me. A week after the deposit, I got a “funds failed to clear” message from my bank. No charge to me, but the “money” that appeared to be in my balance disappeared.

    Person 2 texted me the image of their FedEx note, and when I said I would wait a week for the check to clear, they asked me to tear up the check and send them a picture. I declined. Person 3 sent a check blindly, saying they were trusting me. I ignored future texts, but they persistently kept checking for 12 days. In all cases, these are checks on real banks, but fake names and accounts.

    Checks are insecure. And just like plenty of data replication systems that try to synchronize data between two databases, there can be issues if you do not have a two-phase commit.

    I wrote this so many of you would be aware of a scam that is out there. Watch out and warn your less tech-savvy friends. However, also be careful when you work with data that lives in two places. There is a lot of overhead to ensuring the data is correct in all the systems, and there are good reasons for this. Sometimes eventual consistency isn’t good enough.

    Steve Jones

    Note: A few people are concerned about the check images linked. Those are fake people and fake accounts.

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

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

  • The Book of Redgate: Evidence

    We aren’t the only company that does this, but Redgate Software does try to be data driven. Across my 18 years, I’ve had plenty of people use evidence from customers, from usage data, from market research, and more to justify a decision.

    I think Google and quite a few other companies have called this being “data-driven.”

    2026-06_0203

    The text on the next page continues the sentence:

    not on people’s opinions, the volume of their voices or who they are. When the evidence changes, we are prepared to change our minds. We will thank, and never shoot, the messenger.

    I will say that this has skewed a bit over time, as I find that evidence is subject to interpretation and I’ve certainly seen some people cherry picking evidence to support their decision. Sometimes by asking for certain evidence.

    However, we did realize there were issues and have tried to correct. I was part of a yearlong project last year that impacted marketing, product, and engineering where we focused on getting more information from more customers, and especially being careful to get evidence from multiple sources, including different geographies. We had a bias to the UK, so we tried to correct for that, and I think we made some strides.

    That being said, I haven’t seen us shoot or blame the messenger for bad news, though sometimes thanks are sometimes not as sincere as they could be. I understand, because contrary news tends to dampen enthusiasm.

    I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.

  • Never is Not the Policy

    Years ago I worked with a few developers and DBAs that were temp-table happy. As in they defaulted to using temp tables everywhere. This was in SQL Server 6.5, and tempdb was an issue with contention, sizing, and performance. I rewrote so many queries to remove temp tables for our clients that I banned them. I told other developers they could never use temp tables in their SQL code. They, of course, would try to submit code with temp tables in our VCS (Visual SourceSafe at the time), but an early, pre-automated CI/CD would notify me and I’d have the developer rewrite their code.

    There were situations that didn’t perform well with a single query, and we did allow some temp tables. The point wasn’t the ban them entirely, but stop them from being a crutch for developers or a first choice. I wanted them to think about the problem first and try to solve it with SQL. If performance was an issue, then we’d look at a temp table.

    Recently, I saw a post from Jeff Iannucci that noted there are settings you should never change. These were database-level or instance-level settings that he suggests you leave the defaults, or leave a specific setting chosen. An example of the latter is Page_verify set to checksum. The default in older databases, upgraded through different versions, can be none or torn page detection enabled. Fix that if you see it.

    Examples of other settings are things like Auto Shrink and Auto Close, which shouldn’t be enabled. These types of settings should be left off, well, with a caveat from me. There are narrow places where you might want certain things turned on. For example, Auto Close isn’t the worst thing in the world, and there places where it makes sense. Dev servers with a large number of databases that aren’t often used might get help here in conserving resources. Same for production instances where a lot of older databases are kept around for archival, but we don’t want them open and consuming any resources without an explicit connection.

    I don’t mind DBAs or developers having “never” as a policy for certain things, with the caveat that this isn’t a forever rule, but one that strongly sets a guideline that we don’t create exceptions for without a very good reason. Staffs change, internal knowledge is lost or narrowly shared, and often inexperience can creep into your environment. These strongly worded guidelines, even with “never” in them, help to keep everyone on the same path.

    Strong opinions, loosely held. We change our minds and grant exceptions when there is evidence to do so.

    Steve Jones

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

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