Sometimes technical debt doesn’t stem from a botch but from a reasonable decision made too early. That’s what Wise has once again highlighted after its co-founder and CEO, Kristo Käärmann, admitted on X that the company is close to exhausting the 32-bit namespace it chose for transfer IDs when writing the first lines of code back in 2010.
The anecdote carries a bit of an insider joke among engineers and a classic lesson in software architecture. A 32-bit signed integer allows up to 2,147,483,647 positive values. A 64-bit signed integer raises that number to 9,223,372,036,854,775,807. On paper, the difference is monumental. In practice, 16 years ago it was hard to imagine that a fintech like this would come so close to hitting that ceiling.
When rapid growth turns a bad choice into a headline
Käärmann explained it with irony. He acknowledged that choosing int over long was a short-sighted decision, joking that perhaps his engineers didn’t value the $17 savings in storage over the years enough. Beyond the joke, the comment summarizes how real technical debt works: a small decision, almost invisible at the start of a project, can resurface years later as a scale problem.
The interesting part here is that Wise isn’t a startup that failed due to a poor database design. Quite the opposite. Wise has reached this point because it has grown to a volume most companies never reach. In its fiscal year 2025, the firm reported 15.6 million active customers and £145.2 billion in cross-border transaction volume. Viewed that way, the ID problem doesn’t seem like a dramatic error but rather a logical consequence of scaling much more than its founders probably envisioned in the early years.
The database always remembers
In software development, some decisions seem trivial early on: the data type of a column, the format of a primary key, field length, how to model a state, or the initial structure of a table. In an early phase, all that seems reversible. The trouble begins when that design shifts from supporting thousands of records to hundreds of millions or billions.
Choosing a 32-bit integer for sequential IDs was a perfectly common decision for years. In fact, it was enough for countless business applications for a long time. What changes in companies like Wise isn’t so much the theory as the scale. When a platform has been generating IDs tied to real business operations for years, altering that field is no longer just a schema change: it impacts tables, indexes, internal APIs, reconciliation processes, analysis tools, legacy systems, and often external integrations.
That makes incidents like this very educational. The database never forgets. A line written at the beginning of the project can stay in production for decades, hidden beneath layers of product, new features, and international growth—until one day it becomes a bottleneck.
It’s not the first software Cautionary Tale
This case inevitably reminds us of other technical perspective errors—from the two-digit year storage in legacy systems from the 80s and 90s to past decisions on routing, capacity, or format that seemed efficient at the time but ended up too small.
The difference here is that there’s no drama or visible crisis for the customer. It hasn’t been presented as a service outage or serious operational incident. What has surfaced is a sign of maturity: Wise has reached the point where its early engineering decisions are showing at a massive scale. And that, within reason, is very good news for a software company.
It also reveals something important about how actual technology products are built. Nearly perfect architecture almost never exists on day one. Founding teams make trade-offs. They prioritize going to market, validating a model, delivering a product into customers’ hands, and solving urgent problems with current resources. Later, if the company survives and grows, they face the bill for those decisions.
Lessons for new startups
The message shouldn’t be that every startup must design from the start as if managing billions of operations—that’s unrealistic and often counterproductive. Over-engineering too early also costs time, complexity, and money.
The more useful lesson is another: some structural decisions deserve a longer perspective. Choosing a 64-bit ID in a modern database rarely breaks the bank for a startup, but it can prevent a delicate migration years later. The same goes for certain partitioning schemes, versioning strategies, or key models.
Wise hasn’t publicly detailed how it plans to resolve this limit, but the industry generally considers solutions like expanding data types, migrating to bigint, introducing new sequences, or redesigning ID generation methods—without breaking compatibility. None of these options are trivial once the system is in full production handling real money.
An enviable technical debt
There’s one last, perhaps healthiest perspective: in a sector where “technical debt” is often associated with fragility, poor practices, or impulsive decisions, Wise’s situation represents an almost enviable variant—debt caused by significant growth.
It’s not trivial for a founder to acknowledge a decision made in 2010 with humor and admit it was shortsighted. Even less so when that decision only becomes problematic because the company has scaled massively. Many technologies are designed with the next quarter in mind. Few last long enough for their early mistakes to still be a concern 16 years later.
FAQ
How many values can a signed 32-bit integer ID allow?
Up to 2,147,483,647 positive values—the standard limit for a signed 32-bit integer.
Why didn’t they use 64 bits from the start at Wise?
Kristo Käärmann himself admitted it was a short-sighted decision made in 2010 when writing the first lines of code.
Is it serious that Wise is reaching its ID limit?
It’s a significant technical issue but not necessarily a disaster. It actually reflects that the company has scaled enormously and now needs to fix an old architectural choice.
What is commonly used today to avoid this problem?
Most often, 64-bit integers (bigint or equivalents) for sequential keys with high growth potential, or alternative ID generation systems depending on the case.