Monday.com replaces MySQL item IDs with DynamoDB service to scale boards

A tiny counter became a platform decision

monday.com’s move away from a single MySQL-based item ID shortcut is the kind of scaling choice that quietly separates mature teams from teams still living on patches. Board items started with a simple serial counter in one master database, which was fine until growth turned that master into both a bottleneck and a single point of failure.

The key constraint was not just volume. Board item IDs had to remain integers because too much legacy logic, and too many downstream services, already depended on that format. Swapping to UUIDs might have sounded cleaner in theory, but it would have forced a huge rewrite across the codebase and risked breaking the workflows that make monday.com’s Work OS feel seamless to customers.

Why the old shortcut stopped working

This is where the story moves beyond backend trivia and into product reliability. monday.com has described its platform as a cloud-based Work OS, and its boards are the core unit of work, the place where people view items, create items, and update columns. When the engineering team says every database hiccup can affect customers’ ability to interact with boards, that means item-ID generation is not an internal housekeeping task. It is a customer-facing reliability issue.

The scale of the problem also explains why the company could not keep treating IDs as a minor implementation detail. monday.com has said its largest enterprise accounts can have tens of thousands of employees, which means a single board can sit inside extremely large, busy workflows. In that environment, even a narrow dependency like ID assignment needs the same kind of resilience and observability as the rest of the platform.

The answer was not another shortcut

Instead of stretching the old model, monday.com built a centralized ID Generator Service backed by DynamoDB. Rather than auto-incrementing a counter for every insert, the service leases ranges of IDs to clients, which reduces pressure on the database and gives the platform more room to absorb growth.

That design choice matters because it shows the difference between a quick fix and an infrastructure decision. A client SDK talking directly to DynamoDB might have reduced latency on paper, but it would also have spread complexity across clients, created maintenance headaches, and increased the risk of hot-partition throttling. By putting the logic behind a service, monday.com kept control in one place, preserved flexibility for future changes, and built a shock absorber for traffic spikes.

For engineers inside monday.com, that is a familiar pattern: centralize the hard part, keep the operational burden visible, and make the service a reusable piece of platform infrastructure instead of a one-off workaround. For product managers, the lesson is equally blunt: if every team keeps solving the same bottleneck in its own way, the company is not scaling, it is accumulating technical debt with a new label.

How the rollout avoided a real-world shock

The most practical detail in the rollout was also the most revealing. Before fully switching traffic, the team stress-tested the new infrastructure by generating IDs in the background and discarding them. To do that safely, it used a fake entity key, `shadow.boards.item`, so the test path would not advance the real counter during the rollout.

That kind of shadow testing is exactly what mature platform teams do when they are trying to remove risk without freezing delivery. It lets engineering measure throughput, validate assumptions, and surface failures before customers feel them. In a company built around boards, items, and constant user interaction, that is the difference between a controlled migration and a reliability incident.

The fact that the team chose a service also says something about monday.com’s engineering culture. The company has emphasized owning infrastructure end to end and maintaining centralized operational visibility, which fits the way this project was handled. The goal was not to delegate complexity outward. It was to make the system easier to operate, easier to observe, and less fragile under load.

Why DynamoDB was the right fit, even without auto-increment

Amazon Web Services has noted that DynamoDB does not natively provide auto-increment, and AWS published guidance in 2023 on how teams can implement it anyway. That matters because monday.com’s choice was not a unique workaround for a unique mistake. It was a recognizable design pattern for teams that need ever-increasing numeric IDs but no longer want those IDs tied to a single relational bottleneck.

The move also underscores a broader management rule that too many teams ignore: when a legacy pattern becomes central to performance and reliability, the question is no longer whether the old approach still works today. The real question is how much future slowdown it creates for everyone else. At monday.com, the answer was to build a durable service around a known constraint rather than let a historical design decision keep defining the platform.

That tradeoff will feel familiar to anyone working in SaaS. The temptation is always to keep patching the database, keep adding a little logic here and a little caching there, and hope the next release buys more time. But once a core primitive starts blocking scale across teams, the stronger move is to isolate the dependency and give it dedicated infrastructure.

What this says about monday.com’s next phase

This ID project also fits into a larger architectural direction. monday.com has been publishing adjacent work on data entities, board and event infrastructure, and monolith-related decomposition, which suggests the company is steadily reshaping the plumbing beneath a large Work OS rather than just chasing isolated performance wins.

That matters for every function inside the company. Engineers get a clearer platform to build on, product teams can ship features without worrying that a hidden database shortcut will buckle under growth, and sales teams can promise reliability to larger customers with more confidence. In a business where enterprise accounts can span tens of thousands of employees, platform engineering is not background work. It is part of the customer experience.

The bigger management lesson is simple: stop treating old database shortcuts like they are harmless just because they once worked. When a core system starts slowing everyone down, the mature response is to invest in infrastructure that removes the bottleneck for good. monday.com’s ID generator is a small technical change with a large organizational message: scale is won by replacing fragile habits before they become shared pain.