Voice of the DBA

Author: way0utwest

  • I Don’t Want To Do XX

    Every job is a job on some days.

    I’ve said this to my kids and others I’ve mentored over the years. I’ve probably written that here, and I truly believe it. When you work at a job, some days are bad days. There are always days you don’t want to do the work. There are also likely some days that you dread starting. Whether you work for someone else or run your own business, there will be times you aren’t completely in control of the work and wonder how you ended up in this situation. Even if you’re self-employed, you have clients that sometimes dictate your day.

    I’ve worked for myself in the past, and I currently have an amazing job as an advocate/architect with Redgate Software. I get to travel all over and talk about AI readiness, DevOps / Database Change Management, Database Intelligence, and random SQL Server stuff. Usually it’s a lot of fun, but at times it can be hard. If you see me not engaging at an event, it might be that I’ve been on the road a lot while still having lots of other work commitments to manage. I might be worn out and need a break. Those often are tough days. (FYI – We always need good people and have a few spots open.)

    Lately I’ve been hearing people talk a bit about AI and how it sometimes takes the joy out of work. That might be because it’s doing the stuff you enjoy doing. This conversation with Casey Muratori on using AI is revealing. He’s not using AI because he loves programming. He doesn’t want to have AI doing his coding.

    That’s interesting, and it got me thinking about daily tasks, the things we do and what we might send off to be handled by an assistant.

    What things do you not want to do at your job?

    That’s the question today. Let me know what things you wish you could get someone else to do, or some robot to handle for you. I know lots of people wish they had a robot to do the laundry or dishes at home. What tasks at work would you want a trustworthy helper to handle?

    Steve Jones

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

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

  • The Book of Redgate: Hours

    I have said and written this many times: Redgate Software is the type of company I’d want to build if I founded another company. It’s a great place, and one of the things I appreciate is that we value outcomes.

    One of our values is:

    2026-06_0204.

    The text on the next page continues the sentence:

    What you achieve is more important than how long it takes.

    Building software is challenging, and building software that can be sold is difficult. We’ve had lots of successes and some not-successes. However, we work towards building the software and celebrate the achievements.

    However.

    If you’ve built software, you know it usually takes longer than expected and people want it sooner. Many teams know me as the “do it faster” guy. I know software takes time, but I also know that in the business of selling software, we need focus on things that are useful and valued by customers.

    I don’t complain that it takes too long to build everything, but I do press on the focus to get the important things done first, which aren’t always the fun or easy things.

    Ultimately we as a company appreciate when we have something done and working for customers. We don’t go back and lessen the importance of the effort because of the time it took. We do look to see if we can do better in the future, which is something I’d hope most software engineers would do.

    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.

  • The Cost of Multiple Platforms

    I ran into an interesting post that noted the modern data platform can have a bunch of different systems underlying it. The example might be that your “software” could use PostgreSQL, MongoDB, Cassandra, Clickhouse, and something NewSQL (Spanner, CockroachDB, etc,). Some of you might think that’s not reality, but keep in mind that for a lot of your organizations, the “software” is what the customer uses. I’m sure my bank has multiple systems behind the mobile app I use to pay for things, move money, check balances, etc. I would guess there is some DB/2, SQL Server, and some analytics or No/NewSQL stuff in there. Hidden as different applications that make up the “app”, but they are still in there from my perspective as a user of the app.

    No one intentionally designs software like this, but we still see it. They might not even have 5 or 6 platforms in their organization, but almost none of the customers I work with have less than 3. Somehow, somewhere, someone added a PostgreSQL server to an Oracle/SQL Server environment. MongoDB crept in when someone thought it was a better store than DB/2 or MySQL. An article written about how Facebook or Spotify or some other high tech company used Cassanda or Snowflake inspired a developer to add that to their toolbelt and build it into their application.

    And the ease with which the cloud makes experimentation quick and cheap causes a spread of your database estate.

    There’s a cost to having all these systems. Either an organization hires separate sets of experts to manage Ops, or they try and train lots of individuals to run multiple systems. It can be done, but those lightly trained people who have to focus on remembering the differences between SQL Server, PostgreSQL, and MongoDB will work slower. They’ll solve problems with a higher MTTR. Even if they have a single pain of glass, like Redgate Monitor, they still won’t be as effective as the number of platforms grow. It’s just human nature. And if you hire separate teams, that’s a cost as well.

    Heck, I’m a pretty good DBA and a good volleyball coach, but I get confused. When I got voluntold to manage DB/2 systems in addition to SQL Server, I got less done every day. When I coached two volleyball teams at the same time, I was less effective with each. It’s hard to keep focused on multiple similar things. Add in the complexity of not only separate paradigms, but different ways to manage things in the cloud or on-premises and the operational cost is high.

    I’m not sure it exceeds any licensing cost or the cost of limiting what platforms developers can use. I would argue only allowing 1-2 platforms just makes you more efficient and your staff more effective.

    However.

    That’s not the world. Even if I mandated that, often some external even changes my world. Companies get bought and integrated. New COTS software is needed, and it will, of course, run only on a database platform we don’t run.

    There’s a serious operational cost to adding new platforms that few consider. Even if they did, I’m not sure anything would change.

    Steve Jones

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

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

  • PostgreSQL Support in the Data API Builder

    Next week I’m at VS Live in San Diego (register and join me) and one of my talks is on the Data API Builder. I want to show how this gives you REST, GRAPHQL, and MCP access. As a part of the talk, I also wanted to show this working across platforms, so I’m showing this in PostgreSQL as well.

    I’ve been experimenting this in a few ways, but I decided to see how hard it was to add PostgreSQL support. I decided to follow a similar structure as my SQL Server demos, which are all in my GitHub repo.

    First, I added a .env file, which has the credentials. THIS IS A DEVELOPMENT structure, and not something you’d deploy from a repo. Secure your production stuff! This is my local file (in .gitignore), but it’s a simple connection string.

    2026-08_0375

    Next, I copied (well, I guided Claude to do this)  my demo01.cmd and edited it to say the type is “postgresql” instead of SQL Server. The new file went into a separate folder as (demo01.cmd)

    2026-08_0375

    I had it copy the demo02.cmd and alter this for the PostgreSQL Pagila sample db, which is installed and running on my machine.

    2026-08_0376

    Note, this errored out at first, with the note that DAB doesn’t support the PostgreSQL array type. I ended up having Claude create a view that skips this column and the column that is a vector type. Hopefully those will be supported soon by DAB.

    2026-08_0373

    Next, dab start, and I had a running API server over my PostgreSQL database in just a few minutes. Here’s my Bruno query of the GraphQL endpoint for Pagila.

    2026-08_0377

    Not enough people are using or trying the Data API Builder. This is truly an easy way to get a usable API over your database without a lot of data access layer work for developers.