[{"content":"Build a SQL Server Estate Registry: Inventory 25K Databases with PowerShell Every estate-management failure I have watched starts the same way. Somebody asks how many databases we have, and the room goes quiet. The honest answer is a shrug and a spreadsheet someone updated in March.\nA registry fixes the shrug. Not a spreadsheet. Not a wiki page. A queryable store that answers, in seconds: what exists, where, what version, who owns it, and how much it matters. This post builds one, with the actual scripts.\nThis is the first deep-dive from the estate management operating model. Everything there reads from or writes to the registry you are about to build.\nKey Takeaways\nA minimum viable registry is four tables: Instance, Database, Ownership, Environment. Everything else is decoration until those answer queries. Discovery is a solved problem: PowerShell plus dbatools sweeps any estate that answers a connection string. The unsolved parts are cadence and drift. Daily sweeps beat hourly ones at fleet scale. Drift moves at human speed, and a sweep that costs more than the drift it catches is overhead, not hygiene. New databases get marked for review, missing ones get quarantined, and nothing gets deleted by automation. Deletion is a human decision with a paper trail. Why Spreadsheets Die The failure mode is never laziness. It is entropy with a work queue.\nNew databases appear because an app team restored a backup to \u0026ldquo;just test something.\u0026rdquo; Old databases zombie because the migration finished but nobody dropped the source. A vendor install creates three databases and mentions it in a PDF nobody reads. None of these events page the DBA. The spreadsheet learns about none of them.\nAt twenty instances you can outrun entropy by walking the CMS list every Friday. At three hundred, the walking is the job. The registry inverts the relationship: automation feeds the store, and the store feeds the automation.\nIn the estate I operate, daily sweeps catch a handful of undocumented databases in a typical week. Some weeks none, some weeks a dozen. The count matters less than the certainty that nothing lives more than 24 hours unregistered.\nThe Minimum Viable Registry Schema Four tables. Resist the urge to add a fifth until the first four answer questions in production.\nCREATE TABLE registry.Instance ( InstanceName sysname NOT NULL PRIMARY KEY, DnsName nvarchar(260) NOT NULL, Version nvarchar(64) NULL, Edition nvarchar(128) NULL, PatchLevel nvarchar(64) NULL, FirstSeen datetime2 NOT NULL DEFAULT sysutcdatetime(), LastSeen datetime2 NOT NULL DEFAULT sysutcdatetime() ); CREATE TABLE registry.Database ( DatabaseId int IDENTITY PRIMARY KEY, InstanceName sysname NOT NULL REFERENCES registry.Instance(InstanceName), DatabaseName sysname NOT NULL, SizeMB bigint NULL, RecoveryModel nvarchar(20) NULL, CompatLevel smallint NULL, LastBackup datetime2 NULL, LastDbcc datetime2 NULL, FirstSeen datetime2 NOT NULL DEFAULT sysutcdatetime(), LastSeen datetime2 NOT NULL DEFAULT sysutcdatetime(), CONSTRAINT UQ_Database UNIQUE (InstanceName, DatabaseName) ); CREATE TABLE registry.Ownership ( DatabaseId int NOT NULL REFERENCES registry.Database(DatabaseId), Application nvarchar(128) NULL, Team nvarchar(128) NULL, CriticalityTier tinyint NULL -- 1 = crown jewels, 3 = mystery box ); CREATE TABLE registry.Environment ( DatabaseId int NOT NULL REFERENCES registry.Database(DatabaseId), EnvironmentName nvarchar(20) NOT NULL -- prod / staging / dev / unknown ); Two design notes. First, FirstSeen and LastSeen are the whole drift-detection system. Everything else derives from comparing them. Second, criticality tier is a tinyint, not a paragraph. You will use it to sort patch rings later, and paragraphs do not sort.\nThe Discovery Sweep dbatools does the heavy lifting. If you are running fleet operations without it, stop here and install it first; writing fleet code without dbatools is self-harm.\n# Sweep-EstateRegistry.ps1 # Daily discovery sweep: enumerate instances, upsert registry, mark LastSeen. [CmdletBinding()] param( [Parameter(Mandatory)] [string]$RegistryServer, # where the registry database lives [Parameter(Mandatory)] [string]$CmsGroup, # registered-server group to sweep [string]$RegistryDatabase = \u0026#39;EstateRegistry\u0026#39; ) $ErrorActionPreference = \u0026#39;Stop\u0026#39; $targets = Get-DbaRegisteredServer -SqlInstance $RegistryServer -Group $CmsGroup foreach ($target in $targets) { try { $inst = Get-DbaInstance -SqlInstance $target.Name -ErrorAction Stop Invoke-DbaQuery -SqlInstance $RegistryServer -Database $RegistryDatabase -Query @\u0026#34; MERGE registry.Instance AS t USING (SELECT \u0026#39;$($inst.Name)\u0026#39; AS InstanceName) AS s ON t.InstanceName = s.InstanceName WHEN MATCHED THEN UPDATE SET DnsName = \u0026#39;$($inst.ComputerName)\u0026#39;, Version = \u0026#39;$($inst.Version)\u0026#39;, Edition = \u0026#39;$($inst.Edition -replace \u0026#34;\u0026#39;\u0026#34;,\u0026#34;\u0026#39;\u0026#39;\u0026#34;)\u0026#39;, PatchLevel = \u0026#39;$($inst.Build)\u0026#39;, LastSeen = sysutcdatetime() WHEN NOT MATCHED THEN INSERT (InstanceName, DnsName, Version, Edition, PatchLevel) VALUES (s.InstanceName, \u0026#39;$($inst.ComputerName)\u0026#39;, \u0026#39;$($inst.Version)\u0026#39;, \u0026#39;$($inst.Edition -replace \u0026#34;\u0026#39;\u0026#34;,\u0026#34;\u0026#39;\u0026#39;\u0026#34;)\u0026#39;, \u0026#39;$($inst.Build)\u0026#39;); \u0026#34;@ $dbs = Get-DbaDatabase -SqlInstance $target.Name -ExcludeSystem foreach ($db in $dbs) { Invoke-DbaQuery -SqlInstance $RegistryServer -Database $RegistryDatabase -Query @\u0026#34; MERGE registry.Database AS t USING (SELECT \u0026#39;$($inst.Name)\u0026#39; AS InstanceName, \u0026#39;$($db.Name -replace \u0026#34;\u0026#39;\u0026#34;,\u0026#34;\u0026#39;\u0026#39;\u0026#34;)\u0026#39; AS DatabaseName) AS s ON t.InstanceName = s.InstanceName AND t.DatabaseName = s.DatabaseName WHEN MATCHED THEN UPDATE SET SizeMB = $($db.SizeMB), RecoveryModel = \u0026#39;$($db.RecoveryModel)\u0026#39;, CompatLevel = $($db.CompatibilityLevel -replace \u0026#39;Version\u0026#39;,\u0026#39;\u0026#39;), LastBackup = \u0026#39;$($db.LastFullBackup)\u0026#39;, LastSeen = sysutcdatetime() WHEN NOT MATCHED THEN INSERT (InstanceName, DatabaseName, SizeMB, RecoveryModel, CompatLevel, LastBackup) VALUES (s.InstanceName, s.DatabaseName, $($db.SizeMB), \u0026#39;$($db.RecoveryModel)\u0026#39;, \u0026#39;$($db.CompatibilityLevel -replace \u0026#39;Version\u0026#39;,\u0026#39;\u0026#39;)\u0026#39;, \u0026#39;$($db.LastFullBackup)\u0026#39;); \u0026#34;@ } } catch { Write-Warning \u0026#34;Sweep failed for $($target.Name): $($_.Exception.Message)\u0026#34; # Failure is data too: an instance that does not answer is an instance to chase. } } The script is deliberately boring. Connect, enumerate, MERGE, move on. Every clever thing you add here is a thing that breaks at 2 a.m. in month seven.\nRun it from a SQL Agent job on the registry host, or from any scheduler that can hold a PowerShell session. The scheduler does not matter. The cadence does.\nCadence: Why Daily, Not Hourly Hourly sweeps feel diligent. They are mostly waste.\nDrift moves at human speed. Databases get created during business hours by humans doing work. A sweep that runs at 04:00 catches everything that happened yesterday with hours to spare before the 08:00 standup. The sixteen sweeps in between catch the same registry you already had, plus connection load on every instance in the estate.\nAt three hundred instances, a full sweep touches three hundred listeners, three hundred logins, three hundred error logs. Hourly that is 7,200 touches a day of pure overhead. Daily is 300 touches and you lose nothing. The drift you would have caught at 11:00 still gets caught at 04:00. And the review workflow does not start until a human reads it anyway.\nThe exception is decommissioning projects and migration waves, where drift is deliberately high. Then you sweep the affected ring hourly for the duration and stand the cadence back down.\nDrift Handling: Review and Quarantine The sweep makes drift visible. These two queries make it actionable:\n-- New arrivals: first seen in the last sweep, never reviewed SELECT i.InstanceName, d.DatabaseName, d.FirstSeen FROM registry.Database d JOIN registry.Instance i ON i.InstanceName = d.InstanceName WHERE d.FirstSeen \u0026gt;= dateadd(day, -2, sysutcdatetime()) AND NOT EXISTS (SELECT 1 FROM registry.Ownership o WHERE o.DatabaseId = d.DatabaseId) ORDER BY d.FirstSeen DESC; -- Zombies: not seen for 7 days SELECT InstanceName, DatabaseName, LastSeen FROM registry.Database WHERE LastSeen \u0026lt; dateadd(day, -7, sysutcdatetime()) ORDER BY LastSeen; New arrivals go into a review queue. Somebody looks at each one, assigns ownership and criticality, and moves on. In my queue that takes minutes a week, because the queue is the only place undocumented work can hide.\nZombies get quarantined, not deleted. Seven days unseen means the database went offline, got renamed, got dropped, or the instance stopped answering. Each of those has a different correct response, and none of them is \u0026ldquo;delete the row.\u0026rdquo; Quarantine the row, chase the owner, and let a human close it out. Automation that deletes registry rows is automation that gaslights future you.\nThe Registry Feeds Everything Else This is the payoff. Once the registry is trustworthy, every other discipline reads from it.\nThe automation library builds its target lists from the registry instead of from hardcoded server names. Patch rings are just WHERE CriticalityTier = n. Monitoring scoping is WHERE EnvironmentName = 'prod'. Migration assessment is a GROUP BY over size, version, and dependency metadata that already exists because the sweep put it there.\nThat is the subject of the next posts. The automation library walkthrough covers the discovery-audit-remediation-verify structure that consumes this registry: [INTERNAL-LINK: the automation library → B1 spoke]. Documentation also drifts the moment you generate it. The SqlPowerDoc modernization for SQL Server 2019, 2022, and 2025 fills that gap: [INTERNAL-LINK: document modern SQL Server versions → A2 spoke].\nGetting Started First, today: run Get-DbaRegisteredServer against your CMS and count what comes back. Then compare it to what you thought you had. The delta is the reason this post exists.\nSecond: stand up the four tables on any instance you control. A dedicated tiny registry database on your most boring server is fine. The registry should be the least interesting database you own.\nThird: schedule the sweep for tonight. Tomorrow morning you will have a review queue. It will contain at least one database nobody can explain. That is not a failure of the registry. That is the registry working.\nFrequently Asked Questions How do I inventory all my SQL Servers with PowerShell? Use dbatools: enumerate your instance list with Get-DbaRegisteredServer, then pull databases with Get-DbaDatabase per instance and upsert into a registry database. The full sweep script in this post handles instances, databases, and timestamps in one loop.\nShould I use a spreadsheet or a database for my SQL Server inventory? A database. Spreadsheets cannot tell you when they went stale. Your automation cannot query them. And they cannot distinguish \u0026ldquo;database is gone\u0026rdquo; from \u0026ldquo;nobody updated the row.\u0026rdquo; A registry with FirstSeen/LastSeen timestamps does all three for free.\nHow often should I scan my SQL Server estate for changes? Daily for steady state. Drift moves at human speed, and hourly sweeps mostly reconfirm the registry you already had while adding connection load to every instance. Sweep hourly only during deliberate high-churn work like migrations, then stand down.\nConclusion The registry is the foundation the whole operating model stands on. Four tables, one sweep, two review queries, and the discipline to run them daily. Everything else in this series reads from it.\nThe estate does not care how good your intentions are. It cares what runs on a schedule.\nContinue Learning SQL Server Estate Management at 25,000 Databases: the operating model this post builds on [INTERNAL-LINK: The DBA Automation Library → B1 spoke] [INTERNAL-LINK: SqlPowerDoc for Modern SQL Server → A2 spoke] ","permalink":"https://thedwindlingdba.com/posts/sql-server-estate-registry-powershell/","summary":"\u003ch1 id=\"build-a-sql-server-estate-registry-inventory-25k-databases-with-powershell\"\u003eBuild a SQL Server Estate Registry: Inventory 25K Databases with PowerShell\u003c/h1\u003e\n\u003cp\u003eEvery estate-management failure I have watched starts the same way. Somebody asks how many databases we have, and the room goes quiet. The honest answer is a shrug and a spreadsheet someone updated in March.\u003c/p\u003e\n\u003cp\u003eA registry fixes the shrug. Not a spreadsheet. Not a wiki page. A queryable store that answers, in seconds: what exists, where, what version, who owns it, and how much it matters. This post builds one, with the actual scripts.\u003c/p\u003e","title":"Build a SQL Server Estate Registry: Inventory 25K Databases with PowerShell"},{"content":"SQL Server Estate Management at 25,000 Databases: The Operations Manual Nobody Wrote I run 25,000 databases across more than 300 Azure VMs. I\u0026rsquo;m the only senior DBA.\nMost estate-management advice assumes you can name your instances from memory. That stops working somewhere around server forty. I stopped counting names years ago and started counting ratios instead.\nThis post covers the operating model that keeps the estate alive. It isn\u0026rsquo;t a product pitch. Search for \u0026ldquo;SQL Server estate management\u0026rdquo; and you get wall-to-wall vendor pages: Redgate, Quest, Aireforge, IDERA. Every one of them sells a tool. Tools are fine, but tooling was never the bottleneck at this scale.\nNine follow-up posts go deep on each discipline. This one covers the model itself and links out to all of them.\nKey Takeaways\nEstate management at scale breaks into four disciplines: a living inventory, an automation library, coordinated maintenance, and wide-cheap monitoring. They have to operate as one system. A 25,000:1 databases-to-DBA ratio is survivable only when every repeated human action becomes a script. SQL Server 2022 Enterprise lists at $15,123 per 2-core pack (Microsoft pricing, retrieved 2026-10-03). At fleet scale, licensing math drives architecture more than performance does. The career math favors this skillset: database architects earn a median $139,500 vs. $104,620 for DBAs (U.S. Bureau of Labor Statistics, May 2025, retrieved 2026-10-03). What \u0026ldquo;Estate Management\u0026rdquo; Actually Means at This Scale SQL Server estate management is the discipline of keeping hundreds of servers and thousands of databases enumerated, patched, backed up, and observable as one system. Not four consoles. Not four teams. One loop.\nAn estate is the complete set of SQL Server instances and databases an organization is responsible for. A deployment ring is a group of servers patched together as one wave, ordered by risk. The registry is the queryable inventory store that every other discipline reads from and writes to.\nThe vendor definition stops at tooling: buy the dashboard, point it at your instances, done. That works at twenty instances. At three hundred, the dashboard is the easy part. The hard part is deciding what the dashboard is allowed to touch, in what order, with what rollback, and who gets paged when it\u0026rsquo;s wrong.\nThe labor context matters here. The U.S. Bureau of Labor Statistics counted about 75,000 database administrator jobs in 2025 (BLS OOH, retrieved 2026-10-03, linked above). The whole profession is roughly three times the size of my database count. Most software, most advice, and most conference talks are built for human-scale estates where one DBA minds a dozen servers.\nThis guide assumes the other case, where you\u0026rsquo;re outnumbered five figures to one.\nEverything below comes from operating one production estate: 25,000+ databases, 300+ Azure VMs, single senior DBA. Numbers are anonymized to ratios where employer details would leak, but the ratios are real.\nThe Registry: You Can\u0026rsquo;t Manage What You Can\u0026rsquo;t Enumerate A living inventory database is the foundation of everything else. Not a spreadsheet. Not a wiki page someone updated in 2023. A queryable store that answers, in seconds: what exists, where, what version, who owns it, and how much it matters.\nThe minimum viable schema:\nInstance: name, IP/DNS, version, edition, patch level Database: name, size, recovery model, compatibility level, last backup, last DBCC Ownership: application, team, criticality tier Environment: prod, staging, dev, the-mystery-box-nobody-claims Collection is a solved problem. PowerShell plus dbatools covers discovery across any estate that answers a connection string. The unsolved problems are cadence and trust: how often you sweep, and what you do when reality disagrees with the registry. Disagreement is constant. New databases appear. Old ones zombie. Nobody tells the DBA.\nTo keep the registry as up to date as possible, the system performs daily sweeps looking for new SQL instances and databases. If it finds one, it adds it to the registry and marks it for review. Automation feeds the registry, and the registry feeds automation.\nThe first deep-dive builds the full registry, with scripts: [INTERNAL-LINK: build the estate registry → A1 estate registry spoke].\nDocumentation also drifts the moment you generate it, so the series covers modernizing SqlPowerDoc for SQL Server 2019, 2022, and 2025: [INTERNAL-LINK: document modern SQL Server versions → A2 SqlPowerDoc spoke].\nThe Automation Library At 300+ servers, anything a human does twice is a script waiting to exist. Anything a human does weekly is a script that already should exist.\nThe library has a structure, and the structure matters more than any individual script:\nDiscovery: feeds the registry Audit: compares reality to policy (patch level, config drift, permission drift) Remediation: idempotently fixes the issues the audit found Verification: covers your ass and makes sure you don\u0026rsquo;t end up answering questions Monday morning about why things aren\u0026rsquo;t in the state you said they would be Idempotency matters more than any individual script. A script that can\u0026rsquo;t safely run twice will eventually run twice. At fleet scale, \u0026ldquo;eventually\u0026rdquo; lands on a Tuesday.\ndbatools is the base layer. It\u0026rsquo;s the closest thing the SQL Server world has to a standard library, and writing fleet operations without it is self-harm. On top of it you build the estate-specific layer: your naming conventions, your rings, your escalation paths, your quirks.\nThe full library walkthrough is the fourth post in the series: [INTERNAL-LINK: the automation library → B1 automation spoke].\nCoordinated Maintenance: Patching and Backups as Fleet Operations Maintenance windows don\u0026rsquo;t scale linearly with server count. They scale combinatorially with dependency count. Three hundred servers patched one window at a time is three hundred weekends. Nobody has three hundred weekends.\nThe fix is rings. Group the estate into deployment rings: canary first, then low-criticality, then the crown jewels last, with bake time between. Each ring is a wave, and each wave stays small enough to abort without a career event.\nSQL Server 2022 Enterprise lists at $15,123 per 2-core pack; Standard at $3,945 (Microsoft pricing, retrieved 2026-10-03, linked above). Multiply across a few hundred VMs and it quickly becomes apparent why costs can start driving architecture decisions. Consolidation stops being a tidiness project and becomes a budget line with your name on it.\nBackups get the same treatment. Existence isn\u0026rsquo;t the question; every backup job in the world \u0026ldquo;succeeds.\u0026rdquo; The question is restorability, and restorability is only proven by restores. At this scale, restore testing runs as a scheduled fleet operation, not a yearly fire drill. Test-DbaLastBackup exists precisely for this. The trick is running it against thousands of databases without melting the verification box.\nThe deep-dives: [INTERNAL-LINK: patch rings at fleet scale → B2 patching spoke] and [INTERNAL-LINK: verify backups across thousands of databases → B3 backup verification spoke].\nMonitoring Without a Six-Figure Budget At 300 servers, wide and cheap beats deep and expensive. You need to know which server is sick before you need to know why.\nThe tiers that work:\nTier 1, pulse: is it up, is it backed up, is it patching on schedule. Fleet-wide, cheap, no exceptions. Tier 2, vitals: waits, latency, queue depth, job failures. Collected everywhere, alerted selectively. Tier 3, deep dive: Query Store, extended events, the forensic kit. Turned on where it matters, not everywhere. Alert fatigue is a math problem before it\u0026rsquo;s a feelings problem. If every server emails you about every hiccup, you get thousands of emails and read none of them. Alerts have to aggregate by fleet pattern, not by instance. One bad query plan regression across forty databases is one alert. Forty separate emails is a resignation letter.\nThe monitoring build: [INTERNAL-LINK: monitor without a six-figure budget → C1 monitoring spoke]. The forensic side, finding the single bad query hiding in 25,000 databases: [INTERNAL-LINK: find the one bad query → C2 performance triage spoke].\nThe Cloud Question: Migrate, Consolidate, or Hold Azure SQL Managed Instance changes the unit of management. On a VM, you manage a server. In MI, you manage a database. That shift is the strongest argument for migrating, and also the strongest argument for looking carefully before you leap.\nSome workloads gain enormously: the instance-level features are there, the patching disappears, the unit economics improve. Some workloads break in ways nobody warns you about: cross-database queries, odd dependencies, the app that hardcodes a server name in a config file last touched in 2011.\nAt fleet scale, migration is an assessment problem rather than a moving problem. The registry earns its keep again: every database already carries criticality, size, dependency, and drift metadata, so the decision per workload is mostly mechanical. The surprises live in the dependencies the registry didn\u0026rsquo;t know about, which is why the first migration post-mortem always improves the registry.\nThe war stories and the assessment framework: [INTERNAL-LINK: what breaks when you migrate at scale → D1 migration spoke].\nThe Dwindling DBA: Career Math The standalone DBA role is consolidating, and the BLS numbers show the shape of it. Employment for database administrators and architects is projected to grow just 4% from 2025 to 2035 (BLS OOH, retrieved 2026-10-03, linked above). The role isn\u0026rsquo;t disappearing. It\u0026rsquo;s concentrating.\nThe pay split tells you where it concentrates. In May 2025, the median database administrator earned $104,620. The median database architect earned $139,500 (same source). That\u0026rsquo;s a $34,880 annual premium for the version of this job that designs estates instead of administering instances.\nThe part the vendors won\u0026rsquo;t tell you: running a 25,000-database estate already is architecture work. Fleet design, ring strategy, migration assessment, licensing economics. That\u0026rsquo;s the architect job description wearing a DBA badge. The dwindling reads a lot better as a rebrand with a raise attached.\nThe full career argument: [INTERNAL-LINK: from DBA to cloud data architect → D2 career spoke].\nGetting Started First action, today, five minutes: count your estate. One query against your CMS or a Get-DbaRegisteredServer sweep. How many instances, how many databases, and when did you last verify the number?\nSecond: figure out your ratio of databases per DBA. If it\u0026rsquo;s three figures, you need the registry. If it\u0026rsquo;s four, you need this whole series.\nThird: subscribe or bookmark. Nine deep-dives, one per Tuesday, starting with the registry build. Each one ships with runnable scripts, not vibes.\nFrequently Asked Questions What is SQL Server estate management? SQL Server estate management is the discipline of operating all your instances and databases as one system: inventory, automation, maintenance coordination, and monitoring. It becomes necessary somewhere past a few dozen instances, when naming things from memory stops working.\nHow many databases can one DBA manage? With manual methods, a few dozen comfortably. With a registry and an automation library, the practical ceiling moves by orders of magnitude. This guide documents one DBA operating 25,000+. The constraint is whether repeated actions are code, not the count itself.\nWhat\u0026rsquo;s the difference between estate management and a monitoring tool? A monitoring tool tells you something is wrong. Estate management is the operating model that decides what\u0026rsquo;s allowed to be wrong, who fixes it, and how it stays fixed. Tools serve the model. They don\u0026rsquo;t replace it.\nIs the DBA role dying because of the cloud? It\u0026rsquo;s consolidating, not dying. BLS projects 4% growth for DBAs and architects through 2035, with architects earning a median $34,880 more per year (BLS, May 2025, linked above). The work shifts from administering instances to designing fleets.\nHow much does a large SQL Server estate cost to license? More than the hardware. SQL Server 2022 Enterprise lists at $15,123 per 2-core pack (Microsoft pricing, linked above). Across hundreds of VMs, licensing is frequently the largest line item, which is why consolidation belongs to estate management rather than to a finance afterthought.\nConclusion The operating model is the product. Registry first, scripts before headcount, rings instead of windows, monitoring that\u0026rsquo;s wide before it\u0026rsquo;s deep.\nThe estate doesn\u0026rsquo;t care how good your intentions are. It cares what runs on a schedule.\nCloud migration will keep reshaping the unit of management, and the DBA title will keep sliding toward architecture. Both trends reward exactly the skills this series builds.\nContinue Learning Foundation:\n[INTERNAL-LINK: Build a SQL Server Estate Registry → A1 spoke] [INTERNAL-LINK: SqlPowerDoc for Modern SQL Server → A2 spoke] Fleet Operations:\n[INTERNAL-LINK: The DBA Automation Library → B1 spoke] [INTERNAL-LINK: Patching 300 Azure SQL VMs → B2 spoke] [INTERNAL-LINK: Backup Verification Across 25,000 Databases → B3 spoke] Monitoring \u0026amp; Performance:\n[INTERNAL-LINK: Monitoring Without a Six-Figure Budget → C1 spoke] [INTERNAL-LINK: Performance Triage at Fleet Scale → C2 spoke] Migration \u0026amp; Career:\n[INTERNAL-LINK: Azure SQL Migration at Fleet Scale → D1 spoke] [INTERNAL-LINK: From DBA to Cloud Data Architect → D2 spoke] ","permalink":"https://thedwindlingdba.com/posts/sql-server-estate-management/","summary":"\u003ch1 id=\"sql-server-estate-management-at-25000-databases-the-operations-manual-nobody-wrote\"\u003eSQL Server Estate Management at 25,000 Databases: The Operations Manual Nobody Wrote\u003c/h1\u003e\n\u003cp\u003eI run 25,000 databases across more than 300 Azure VMs. I\u0026rsquo;m the only senior DBA.\u003c/p\u003e\n\u003cp\u003eMost estate-management advice assumes you can name your instances from memory. That stops working somewhere around server forty. I stopped counting names years ago and started counting ratios instead.\u003c/p\u003e\n\u003cp\u003eThis post covers the operating model that keeps the estate alive. It isn\u0026rsquo;t a product pitch. Search for \u0026ldquo;SQL Server estate management\u0026rdquo; and you get wall-to-wall vendor pages: Redgate, Quest, Aireforge, IDERA. Every one of them sells a tool. Tools are fine, but tooling was never the bottleneck at this scale.\u003c/p\u003e","title":"SQL Server Estate Management at 25,000 Databases: The Operations Manual Nobody Wrote"},{"content":"Dustin Marzolf. Senior DBA, 13 years on SQL Server and Azure. Sole senior DBA operating an estate of 25,000+ databases across 300+ Azure VMs.\nThis blog documents what the job actually looks like at that scale while the standalone DBA role dwindles around it: the registry, the automation library, patch rings, monitoring economics, migration math, and the career case for reading \u0026ldquo;dwindling\u0026rdquo; as a rebrand with a raise attached.\nEvery post ships with runnable scripts and real fleet numbers, anonymized to ratios where employer details would leak.\nAlso modernizing SqlPowerDoc for SQL Server 2019, 2022, and 2025.\n","permalink":"https://thedwindlingdba.com/about/","summary":"\u003cp\u003eDustin Marzolf. Senior DBA, 13 years on SQL Server and Azure. Sole senior DBA\noperating an estate of 25,000+ databases across 300+ Azure VMs.\u003c/p\u003e\n\u003cp\u003eThis blog documents what the job actually looks like at that scale while the\nstandalone DBA role dwindles around it: the registry, the automation library,\npatch rings, monitoring economics, migration math, and the career case for\nreading \u0026ldquo;dwindling\u0026rdquo; as a rebrand with a raise attached.\u003c/p\u003e\n\u003cp\u003eEvery post ships with runnable scripts and real fleet numbers, anonymized to\nratios where employer details would leak.\u003c/p\u003e","title":"About"}]