A Fine Slice Of SQL Server
Deepak Vohra explains why you might want to look into Podman:
Podman is a relatively latecomer to containerization. Some of you may have invested heavily in the Docker stack of technologies (containerd, dockerd, and Docker Swarm). You may be wondering if there are any benefits to learning about Podman.
Click through for that answer. One thing that does not show up but might influence your decision is licensing: Podman is Apache 2.0 licensed and there are no commercial costs.
Leave a CommentJeremy Schneider provides an alternative:
Kubernetes metric
container_memory_working_set_bytesis used for evicting/killing pods with too much memory use, especially ifmemory request < limit(don’t do this with Postgres). The metric is calculated from cgroups v2memory.statascurrent-inactive_file[source].You’d assume it’s a good metric for memory usage in kubernetes. But with Postgres, this metric is very inaccurate for memory utilization and doesn’t tell you at all if you’re going to OOM crash your database.
Click through to understand what goes wrong, why it does, and what you can use instead.
Leave a CommentVlad Drumea builds a local version of Azure SQL Database:
Microsoft has recently released in private preview (at the time of writing) the Azure SQL Database container image.
This is Microsoft’s solution for folks who want to build and test Azure SQL DB native software without having to incur additional Azure costs just for dev/test/demo work.This provides a local option for developers who want to work on products that require Azure SQL DB’s specific developer surface: T-SQL, drivers, and engine behavior.
Click through to see how this works. As of right now, you’ll need to be in the private preview, but I imagine things won’t change significantly once they move to public preview.
Comments closedCarlos Robles and Vandana Mahtani make an announcement:
Big news: Azure SQL Developer is here, in private preview. It’s the Azure SQL Database engine, on your laptop, in a container. Build against the exact engine you run in the cloud. Ship the same code to Azure. Change one line, the connection string, and you’re in production. Free for local dev and CI. No subscription. No credit card. No catch. Run it yourself, or hand it to an AI agent and watch it go.
That’s pretty neat, especially because there is a surface area difference between Azure SQL Database and SQL Server.
Comments closedGabriele Bartolini makes a comparison:
For years, I resisted writing a direct comparison between CloudNativePG and Crunchy PGO. It felt like the wrong kind of article to write from where I sit. But after several years of both projects maturing, and particularly since Crunchy Data was acquired by Snowflake, I have been asked with increasing frequency how the two operators compare. I now think the time is right. Last week, I wrote Recipe 24 to answer the practical question of how to migrate. This post attempts something harder: an honest assessment of why the two operators differ and what those differences mean for teams choosing a long-term platform for PostgreSQL on Kubernetes.
I will acknowledge Crunchy’s legacy, explain the architectural choices that I believe make CloudNativePG the stronger foundation, point to data where it exists, and flag the areas where my view is unavoidably subjective. I will not pretend this is a neutral document.
Gabriele is a maintainer on CloudNativePG, so take that into consideration. I do appreciate the upfront statement of bias and think the post is well worth reading.
Comments closedAnthony Nocentino performs additional testing:
In my planned failover walkthrough, I showed what happens when you deliberately move the primary role to another replica. That’s the easy case. Now I want to show what happens when the primary pod just disappears unexpectedly, like during a node failure or a container crash. No graceful shutdown, no demotion, just gone.
I ran two test scenarios, each cycling the primary role across all three pods by force-deleting the current primary three times in a row. First, a 5GB TPC-C database idle. Then, that same 5GB database under sustained HammerDB TPC-C load. Six force-deletes total, six successful automatic failovers. I’ll walk through the error log from the promoted replica, the operator’s detection and recovery behavior, and the full timing data.
Read on to see how Anthony’s SQL Server Kubernetes operator handles when things go bump in the night.
Comments closedAnthony Nocentino runs a test:
When building the sql-on-k8s-operator, I wanted to make sure it could handle both planned and unplanned failovers. The easy case is a planned failover, where you deliberately move the primary role to another replica. The harder case is an unplanned failover, where the primary pod just disappears. The operator needs to handle both.
I recently ran a full planned failover rotation on a three-replica SQL Server Availability Group managed by sql-on-k8s-operator, and I want to show you exactly what happens inside SQL Server and the operator during each hop. If you’ve been following my Introducing the SQL Server on Kubernetes Operator post, this is the logical next step: what does the error log actually look like during a planned failover, what does the operator do in response, and how long does the whole thing take?
I ran the same three-hop rotation twice: once with an idle 5GB database to establish a baseline, and once under a sustained TPC-C workload with HammerDB. In this post, I’ll walk through the SQL Server error log entries, the operator’s reconcile behavior, and the timing data for both runs. In the next blog post, I’ll show what happens during an unplanned failover. Let’s go.
Click through to see how it all works.
Comments closedAnthony Nocentino shares a new project:
Are you considering replatforming your SQL Server workload due to recent vendor changes, but still need high availability and disaster recovery? You’re not alone. One of the challenges with running SQL Server on Kubernetes is that there’s no Kubernetes operator available. That means no automated lifecycle management, no automatic failover, and no standard way to bootstrap an Always On Availability Group on Kubernetes.
I’m excited to share it today as an open-source project: sql-on-k8s-operator. Let’s go.
Click through to see what it entails. All in all, that’s really cool.
Comments closedThomas Williams builds a container image:
Running R Markdown via Docker is a big help with deploying those analysis and reports for others to use.
While there are alternatives for deploying R Markdown — the most popular being Shiny Server — they add the hassle of matching R and package versions to the machine where the code was developed, may require IT help, and mean sharing disk, CPU, and memory with other apps on the same server. And there’s also licensing requirements & limitations for the free version of Shiny Server.
R Markdown on Docker avoids some of these issues; a single Docker container = a single app.
Click through for a simple RMarkdown file and Dockerfile.
Comments closedAnthony Nocentino has an update:
Good news for anyone who’s been working around the AVX issue I wrote about in my previous post. Microsoft has fixed it in Cumulative Update 1 (CU1) for SQL Server 2025.
The downside is that CU1 broke other things like database mail, though I suppose you probably aren’t likely to use database mail on a containerized instance of SQL Server.
Comments closed