Run once. Target many.

The deploy took four minutes. The evening is yours.

Choose your databases, press run, and SQL Multicast does the rest.

SQL Server on-premises and in Azure.

SQL Multicast after a run across 12 tenant databases: 48 of 48 script runs succeeded, with every database's results merged into one grid.
02:14 · 0 incidents

One script. Every database. On purpose.

Nobody saw the outage that didn't happen.

SQL Multicast runs your .sql scripts across a named list of SQL Server databases — fifty dev instances, every tenant shard, or the three servers you actually meant. With the guardrails to make sure it was the three you meant.

Prod is
game day.

You've already practiced this. Built for the part of the job that goes wrong quietly.

The completion list inside a SELECT, showing a table's columns with their data types.

01

An editor that knows your schema.

IntelliSense reads real tables, columns and types — by default from a non-production database, so writing a script never touches prod. Every script opens in its own tab, Ctrl+K formats it, and an error leaves a marker on the line that failed.

A target group of twelve tenant databases, eight of them tagged Production.

02

No surprise runs against prod.

Flag a connection as production once. From then on, a run that would touch it stops and asks first. On the command line the answer is a --yes flag, and AI agents hit the same check, so automation cannot skip what the app insists on.

The variables grid: each variable has a type and a value per environment, such as 90 in Production and 30 in Staging.

03

One script for staging and prod.

Put what changes between environments — retention days, a schema name, a row limit — in variables with a value per environment. Switch environment and the same script does the right thing. Variables survive every GO and quote themselves correctly as text, identifier, number or raw.

An error in the Messages panel naming the database, with the editor showing a marker on the failing line.

04

One tenant out of fifty failed? You'll know which.

Every failure names the database, the batch and the line; click it and the editor opens there. Decide in advance what a failure does, per script: carry on, skip the rest of the script, stop that database, or stop everything.

The built-in git panel, with a branch, a commit box and the changed project files.

05

Changes to your targets get reviewed like code.

Connections, target groups and environments are plain files, so adding a server to All Prod goes through a pull request like any other change. No passwords in them — those stay in the Windows credential store. Commit, push and diff from the built-in git panel.

The run history: each past run with its target group, database count, outcome and duration.

06

“What did we run last night?” Answered.

History keeps every run: the target group, how many databases, what succeeded, what failed, and what pre-flight stopped before anything connected. Double-click a run to bring its results back.

Also: Works with Azure SQL Database and Managed Instance, including Microsoft Entra ID sign-in · Finds schema drift between databases before a migration does, with sqlmc list coverage · Lets your coding agent work through MCP, under the same production check

Be the reason it's quiet.

Free to use, properly

Personal, hobby and learning use gets every feature — in the app, the command line and the MCP server — free, with no nag screens and nothing held back to sell you later. The free Community tier is for personal use and covers up to 5 connections and 25 databases per run. Work is Pro, which starts with a 30-day free trial and no card; larger organizations that need more than that can have Enterprise. See where the lines are.

Download free