If you sketched our telemetry platform on a whiteboard at a conference, nobody would take a photo of it. Industrial devices speak over TCP. Messages move through Azure Service Bus. Everything lands in Microsoft SQL Server. The portal is Angular and .NET Core on Kubernetes. There is no exotic streaming layer, no columnar wonder-store, no technology younger than my career.

That stack ingests telemetry from roughly 40,000 industrial monitoring devices and holds 14TB of it, analytics-ready, feeding ML forecasting and AI integrations on top. It runs, it scales, and — after the cost work we did — it's cheap. The unfashionable choices are not incidental to that. They're the reason.

Choose your innovation budget

Every system gets a limited budget of novelty — spend it where it differentiates you. Our differentiation is what we do with the data: forecasting, anomaly detection, insight delivery. So that's where the new technology lives. The plumbing underneath — transport, queueing, storage — is deliberately the most proven thing that meets the requirement, because plumbing that fails at 2 a.m. spends your innovation budget on incident calls.

The question isn't "can SQL Server handle this?" It's "have you done the work to find out?"

SQL Server at telemetry scale is a skills problem, not a product problem

Engineers regularly assume relational databases can't do time-series volume. Mostly, teams haven't done the unglamorous work: partitioning aligned to how the data ages, indexes designed from actual query plans rather than habit, compression on cold partitions, and honesty about which data is hot. Done properly, a well-run SQL Server holds more than a decade of telemetry and answers the questions the business actually asks — while your operations team keeps using tooling and skills they've had for twenty years.

Would something purpose-built for time-series be faster on some queries? Sure. It would also mean a new operational surface, a new failure vocabulary, a new hiring requirement, and a data migration with a hard deadline — all to speed up queries that were never the bottleneck.

Queues are the honest interface

The other quietly load-bearing decision is putting a message bus between devices and storage. Devices in the field misbehave: they buffer during connectivity gaps and dump hours of readings at once, they retry aggressively, firmware bugs make a subset chatty. The queue absorbs all of it. Ingestion pressure becomes a depth metric you can alarm on instead of a database outage you have to explain. Every scaling incident we haven't had, we owe to that buffer.

Boring is a strategy, not a lack of one

None of this is an argument against new technology — the ML layer on top of this platform is as modern as anything. It's an argument for placing novelty deliberately. Fleet telemetry from hardware in the field is the last place you want surprises. The stack nobody photographs is the stack nobody gets paged for, and after 25 years of both kinds, I know which one I'd rather run.