This is a series about the intermediate results of an ongoing effort, not a finished story. It isn't an academic paper — it's a record of real engineering work and the insights that emerged along the way. Also, it's not about AI generating code. The AI angle here is about investigation and research — a careful, governed use of AI as a tool, not an autopilot — something I'll come back to in the final part.
A word on why now, with the project still unfinished: details fade — the small technical decisions, the intermediate observations, the context in which a given call was made. Writing this down while the work is still ongoing is partly how I keep that context from slipping away. And that context matters: it's a reminder that every past decision, mine or anyone else's, was made for reasons that made sense at the time.
One more note: none of this happened instead of product work. All of it ran alongside building new features and fixing bugs — the roadmap never d for it.
On confidentiality: I don't name the Customer, and I avoid any personal data or details a competitor could use. For the same reason, I don't mention anyone by name and refer to colleagues only by role. I won't name them, but I want to acknowledge up front that much of what follows was only possible thanks to the people I work with. The numbers are approximate and rounded — the point is the order of magnitude and the reasoning, not the exact figure.
And a framing to carry through the series: at this scale, optimization is less a sprint than a marathon — yes, probably the most overused metaphor around, but here it genuinely fits: steady pacing beats sprinting, and you get there one careful step at a time.
I'm a software engineer, and I've spent most of my career close to backends and databases. I've also led teams as a technical team lead — though over time I've deliberately shifted back toward more hands-on technical roles, which is where I'm most effective and most at home at the moment. I'm not a DBA by training, but databases have always interested me. Even when you work through an ORM — say, Entity Framework in .NET — you still have to understand what it's doing underneath: reading an execution plan, weighing trade-offs, knowing when the convenient option isn't the right one. We'll get to concrete examples of that throughout this series.
On any team, people naturally specialize. Databases are the area I gravitate toward, so on this project — as on earlier ones — I became the person who spends the most time close to the data layer. Over time, this particular database has become the one I focus on most — a responsibility I took on gladly and grew into with our Team's trust and support, and one I've come to treat as my own: its performance, its cost, its long-term health.
None of this happens in isolation. A lot of what I do is finding and framing problems on the database side — and often fixing them myself, too. I've picked up a good deal of the project's technical detail and business logic along the way. But no one person holds the whole picture, and I lean on the people who know parts of it better than I do. Our Team knows the application, its sister systems, and the business logic, and often turns a raw database observation into the right technical decision — and our Team Leader, in particular, has trusted me and given me the room to research and act. Our Data Analytics Team knows how the data is actually used and what it's supposed to mean. I rely on them all.
A few principles run through everything:
Stability first. The continuity of the business and the application always comes before optimization. Optimization is a way to improve the system, never a reason to put it at risk.
Low-hanging fruits first. We go after the low-hanging fruits before anything else — the biggest return for the least effort. There's no sense chasing a change worth a thousand CPU-seconds a month while one worth a million is still on the table.
Economic efficiency. An optimization has to make sense economically. There's no point spending a hundred hours to save a hundred euros. Every change needs a clear technical and financial justification.
One more thing — not really a technique, more of a mindset. When I run into a technical decision from the past that I'd make differently today, I almost never treat it as someone's mistake. Every decision came with its own context, constraints, and trade-offs — technical, business, sometimes organizational — that I usually can't fully see. In most cases it was the best available choice at the time. Refactoring isn't fixing other people's errors; it's just another step in the normal life cycle of any long-lived system. So wherever I describe changing something in this series, please read it as evolution, not criticism.
And a final principle — less about method than about why any of this matters. This work isn't only about cutting the bill today. The Customer's business is growing fast, and the load on this database keeps growing with it. Optimizing size and compute now is as much about staying ahead of that growth as about saving money — it's how we avoid hitting a wall later, when the same problems would be far more expensive and disruptive to fix. Cost is the visible win; headroom for the future is the real one.
This work is for one of our key Customers — a company running a large IoT platform: an ecosystem of connected systems under heavy load, with data that is mostly time-series in nature. It's a responsible, high-stakes project, and one I genuinely enjoy being part of. I work on one of its key components — an important, high-responsibility part of the platform, though far from the only one. The system is made up of many components working together, and this one is a significant piece of a much larger whole. At its core lies a database that has grown to roughly 18 TB. (Why a relational database is used for time-series data is a fair question, but out of scope here — as are client-side and backend optimizations, except where a database investigation surfaced them.)
When I joined, the component ran on Azure SQL Managed Instance. The database was still relatively small then — a few terabytes — so its size wasn't yet a problem. But it was growing, and we knew it would grow faster as the business scaled. The issue was structural: in that model, the storage ceiling was tied to the compute tier and vCore count, so more data would eventually mean buying vCores we didn't need just for space. We decided to break that dependency before it started costing us, and migrated to Azure SQL Database Hyperscale to decouple storage growth from compute. The migration itself wasn't entirely trivial — a move like this comes with its own technical challenges — but it did what we needed. That migration is where this optimization journey really begins.
Next part: smoothing CPU spikes, and how we took this database from 32 vCores down to 16 — carefully, in several steps, and with more still to come.
Originally published as a LinkedIn post series, " The Database Marathon."