Kendra Little

kendra little

Static Site Improvements: Scheduled Posts, Preview Builds, Robots Writing the CSS

Static Site Improvements: Scheduled Posts, Preview Builds, Robots Writing the CSS

I’ve standardized design, upgraded components, added client-side search, and configured browser caching for this site over the last few weeks. I’ve also adopted a workflow that helps me capture ideas, test changes, and get posts published more easily.

I’m not a web developer, I’m a database nerd. I’m don’t want to be great at CSS. I got this all done with a personal Cursor subscription and an obsessive urge to tag and tidy all my old posts. AI tooling these days makes static websites easier than ever to set up, design, and improve.

If you’re open to AI tooling and want to create a website (or upgrade one you already have), a static site is a great bet.

Continue reading

Erik Darling and Kendra Little Talk AI, Databases, and SQL Server 2025

Erik Darling and Kendra Little Talk AI, Databases, and SQL Server 2025

Erik Darling joins me on the Dear SQL DBA Podcast to chat about AI tools, why they work better for Python and PowerShell than SQL, and what’s exciting (and what’s not) in SQL Server 2025.

Along the way we describe the ONE THING we always want to configure in Resource Governor, why at least one SQL Server 2025 feature should be backported to 2022, and whether the universe is text files all the way down.

Continue reading

Azure SQL Managed Instance Memory-to-Core Math Still Doesn't Work, Even in GPv2

Azure SQL Managed Instance Memory-to-Core Math Still Doesn't Work, Even in GPv2

Microsoft recently announced that Azure SQL Managed Instance Next-gen General Purpose (GPv2) is generally available. GPv2 brings significant storage performance improvements over GPv1. If you’re using GPv1, you should plan to upgrade.

But GPv2 still has the same memory-to-core ratio problem that makes Managed Instance a rough deal for running SQL Server. SQL Server is engineered to use lots of memoryβ€”it’s a rare OLTP or mixed-OLTP workload that doesn’t need significant cache for reliable performance. We’ll have a look at the pricing math.

Continue reading

Index Bloat in Postgres: Why It Matters, How to Identify, How to Resolve

Index Bloat in Postgres: Why It Matters, How to Identify, How to Resolve

Index bloat in Postgres can cause problems, but it’s easy to miss.

I’ve written about how vacuum problems can prevent PostgreSQL from using covering indexes, and index bloat is one of the things that can make vacuum struggle.

Here’s what you need to know about index bloat, how to find it, and how to fix it.

Continue reading

How to See Rowcounts and Execution Time for In-Flight Queries in SQL Server

How to See Rowcounts and Execution Time for In-Flight Queries in SQL Server

I frequently need to see rowcounts and execution time for queries while they’re running. Maybe I’m troubleshooting a slow query that’s still executing, or I want to understand which operators are causing the slowdown before the query completes.

Last week at the PASS Summit I learned some little nuances about how this works that I’d missed.

Continue reading

Three Reasons RDS SQL Server Is Better Than Azure SQL Managed Instance

Three Reasons RDS SQL Server Is Better Than Azure SQL Managed Instance

While every managed database service has high points and low points, there are three things that make RDS for SQL Server shine in comparison to Azure SQL Managed Instance: options for a higher memory:vCPU ratio, a well documented API that works beautifully with python, and fast and effective customer support that isn’t painful to use.

It’s just three things, but they make a huge difference. And these are three things that Microsoft can, and SHOULD, really fix for their cloud database services.

Continue reading

Why Won't PostgreSQL Use My Covering Index?

Why Won't PostgreSQL Use My Covering Index?

Dear Postgres, Why won’t you use my covering index?

Lately I’ve been learning to tune queries running against PostgreSQL, and it’s pretty delightful. One fun question that I worked through struck me something that most Postgres users probably encounter one way or another: sometimes you may create the perfect index that covers a given query, but the query planner will choose to ignore it and scan the base table.

Why in the world would it do that?

Continue reading