Voice of the DBA

Category: Editorial

  • No Defaults Passwords Ever

    I appreciate default passwords on systems. Often, for routers or other devices, I might need a way to connect initially. Or, if I perform a hardware reset, I want some password that I can use to reconfigure things. However, I am pretty good (not perfect, but really good) at changing those passwords to something else. It drives my wife slightly crazy at times, but I save the passwords and stick them in a manager I share with her periodically.

    SQL Server doesn’t store a default password when you install it. If you enable the sa account, you need to create your own password. I primarily deal with containers, and I always set one, usually my own default. However, lots of software either allows a blank password or has a default password set on installation. Oracle even lists theirs in docs. That’s not the worst idea if sysadmins change them, but if they don’t, it’s a threat vector for attackers. I was working with a customer last year who had an Oracle database. I asked them to try a default user/pwd as a test and it worked. I think my head was slowly shaking for the rest of the call.

    Recently, Silicon Valley saw the result of a default password not being changed when someone hacked the crosswalk signals and uploaded fake audio files that played when the signals changed. The vendor (not surprisingly) advised the city to change the passwords to something strong. A somewhat harmless prank, but it’s possible that someone might have made a more nefarious change.

    It’s 2026. We know there are people out there with malicious intentions, as well as those whose prank goes sidesways and have unexpected side effects. There isn’t a good reason to keep default passwords anywhere, including in your own personal devices. These days, connectivity among many systems is a reality with network, Bluetooth, NFC, and who knows what other connections are possible. Your personal devices ought to have defaults changed for your own protection.

    Inside organizations, it can be worse as the weakest link can be exploited to gain access to other systems. Quite a few hacks started in test systems and progressed to accessing production data. Even places we might not expect to be problematic, such as version control systems, have been used by hackers to gain access.

    To me, finding a default password is worthy of a reprimand and a note in whoever’s file forgot to change it. A second offense ought to lead to a suspension at a minimum and possibly termination. This is such a low bar of required security that I can’t think of a good excuse to allow it anywhere.

    Steve Jones

  • Eight Minutes

    When I was at the Small Data 2025 conference, one of the speakers was talking about their work with AI technologies. This person uses it a lot in their day job, often to complete tasks that they would have struggled to work on in the past, mostly because of time constraints, but also a lack of resources. Sometimes this person has an idea, but doesn’t want to distract themselves or others by having them work on a side project.

    During a recent ride in a Waymo (self-driving car), this person had their laptop out and running Claude Code. They gave it a prompt, asking it to build a small app for some data analysis. During the 8-minute ride, the agent had spit out the code, a Readme, and committed this to a git repo. Later, the speaker tried it and found it solved most of his requirements, and then did some other work on the project, as well as having Claude write more code to get something that was beyond a minimally viable app.

    He then gave us this William Gibson quote: “The future is already here — it’s just not very evenly distributed.” I’ve thought about this quote a lot during the last few decades, especially as mobile phones and apps have become prominent. In Colorado, the bandwidth and connectivity have lagged behind other places. When I get frustrated with the mobile network, I want someone to put a copy of that quote above every developer’s desk at Google, Microsoft, Meta, etc. so they realize the way things work in Silicon Valley isn’t how they work elsewhere.

    I’ve been feeling that way about AI tech lately. It’s the future, and it’s not well distributed. There are some successes out there, among lots of failures, but I suspect that some of this is that we’re all working with unevenly distributed models, knowledge, and problems. Some of us are learning to use things better than others.

    So I’m wondering, what do you think you could do in 8 minutes with a coding agent? Take a Waymo if you want, but you might be more comfortable with Claude Code (or another agent) at your desk. Take a problem you’ve been working on and give it to the AI agent. See what happens. Maybe even tackle a side project you can’t seem to find time on which to work and see what happens.

    As I started this, I actually kicked off Claude Code and asked it to load some data from messy files into a database. Across a couple of days (I started late one afternoon), I estimate I spent 10 minutes approving actions, but for less than $5, I had a lot of data loaded (88 files) and the code to do it committed in a repo. With very little effort from me.

    Think about what you could do in a few minutes with an agent. You might get something useful, with little effort or cost. It probably would not be a production-ready app, but it would be something to test an idea, or maybe some code that might inspire others to tackle some of their own backlog.

    What do you want an agent to help you build?

    Steve Jones

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

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

  • JSON Has a Cost

    JSON seems to be everywhere these days. Many application developers like it across all sorts of languages, C#, JAVA, Python, and more. They use it for transferring information between systems, and are comfortable serializing hierarchical object data into JSON from text and de-serializing it back into its various elements.

    For those of us working in relational databases, JSON seems like a blob of information that isn’t easily queried, indexed, or stored. We prefer working with a relational set of data, which brings us into conflict with software developers. We’d like them to convert their objects to a relational structure, and they’d like us to just work with JSON.

    SQL Server has added new JSON functions in SQL Server 2025, expanding the JSON capabilities from previous versions. PostgreSQL has JSON types for a few versions, as has Oracle. Lots of applications are storing JSON data in databases. Unlike XML, however, JSON seems to be working well (overall) as a data storage mechanism.

    Or is it?

    At a recent conference, one of the speakers noted that we do a lot of data movement these days, and there can be a high cost to this as we pay for both compute and network. This data movement often incurs a query cost to get information from the source system. JSON can exacerbate this issue as we may send more data than necessary, and we might find our compute engines don’t support predicate pushdown. Even if we index the JSON, we might still end up querying more data from disks to get what we need. Especially as we move a lot of data to warehouses and lakehouses.

    Using JSON can slow things down. It’s nice for storing a bunch of information quickly and easily, but as we need to work with specific parts of a JSON document, we would likely be better off de-serializing the important pieces into more structured formats that prevent duplication, are easily indexed, and can achieve quick query performance. Everything becomes a little smoother.

    JSON is great, and I do like it, but it’s not a substitute for relational systems and relational models.

    Steve Jones

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

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

  • An SSIS Upgrade

    I came across a post recently on the Microsoft Fabric blog about the evolution of SSIS 2025..I hadn’t heard much about SSIS in SQL Server 2025, so I thought this might provide some info on the investments that Microsoft is still making in Integration Services. I’ve run into a few people in the past year who are still heavily invested in SSIS and run packages daily. SSIS seems to be a technology that isn’t even close to dying for many organizations.

    The blog starts well, delving into the security investments with the change to the SqlClient and TLS 1.3, as well as supporting Strict Encryption. I don’t know many people using this level of security, but it’s good to have SSIS support stronger security. There is also an upgrade for SSIS packages targeting Fabric Data Warehouses if they modify their approach.

    There is also a mention of lift and shift into Fabric Data Factory as an early access program. I wonder how many organizations are looking to still run SSIS packages, but upgrade to Fabric. I’m sure there must be some, and I’m interested if any of you are in this situation. Many of us buy SQL Server licenses, so I would hope Microsoft could invest in a few new SSIS tasks, like SFTP at the least.

    The rest of the post covers Fabric and Azure Data Factory, not SSIS. I understand that Microsoft would prefer everyone abandon SSIS and move to ADF/Fabric, but that’s not what a lot of customers want to do. Many of us have no real need for complexity beyond what SSIS does. What I’d really like to see is a local version of ADF. Many of us still run our own systems and plan to do so for years. If there isn’t going to be an investment in SSIS, which I do understand, then invest in a local version of ADF.

    I doubt Microsoft has much interest in doing work here, especially as the trend towards lakehouses and Parquet files seems to drift further from the idea of SSIS moving data between systems. However, there is still a need for many organizations that might want to build packages to export their data to a data lake on-premises. They might prefer to host their own storage, use Polybase to query those files, and maybe grow into Fabric and Power BI over time.

    Giving options is something Microsoft has often done in the past. Their successes often open the door wider for others to build on their platforms. Their failures are often in places where they try to force everyone to work in a particular way with a particular technology. Expecting everyone to move to ADF/Fabric feels like one of the latter decisions.

    Steve Jones

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

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