Boris Bialek

The through-line

Across everything Boris Bialek says, one argument recurs: moving a badly structured application to the cloud without changing its data model achieves nothing. He calls the alternative approach "Shift and lift, pain and no gain," because "when they move everything to the cloud and it was bad before, it will not be better in the cloud only because it's in somebody else's data center" [1]. The same idea returns as "world of pain reloaded": a lift and shift replicates the complexity, the API problems, the silos, the data duplication and the dependencies you already had, and adds cloud-vendor lock-in on top [2]. What actually changes the economics is rethinking how data is stored, which for him means the document model, and doing it ambitiously rather than incrementally.

The second constant is that this argument is no longer speculative. He tracks a shift in client behaviour from experimentation to commitment: clients have moved from "touching a little toe in the water about Mongo, to going all in building bigger solutions," and are now "not any more discussion about how to move to MongoDB. The question is 'How fast?'" [1]. After one event in London he reports 100 clients calling in unprompted: "It's not our sales people calling upon the clients, the client's calling in. 'I saw it, how do I get started?'" [1]. His role across banking, telco, retail, healthcare and insurance is to industrialise that, and he has continued to argue the industry-solutions and scalability case publicly since [1][4].

On why relational is not the problem but tables are

His history of data starts in the 1960s with IBM's record-based RPG systems, moves to Codd's relational model, and then stops: "since oracle 6 since block mastering and all the work around oracle parallel server not much really happened in relational databases" [2]. Individual features accumulated, but "the underlying core values about availability tables table management are the same," and whatever you bolt on, "at the end you stuff it into a table" [2]. He is explicit that the query language is not the villain: "sql is not the problem i think everybody loves sql," and the real confusion is that "people mixing up the purpose of an sql and the structured query language with a table structured" [3]. He describes the moment of realising this as "really questioning 25 years of my career which is a funny moment you need a lot of beer to do that" [3].

The tabular habit is educational rather than technical. Shown a payment or a SWIFT message, a trained relational mind sees "fifteen thousand tables immediately," but a payment was historically an IOU on paper, and "there is no technical reason why you can't structure it" as one thing; the fragmentation exists because "historically data space was expensive and there was no compression" [3]. He walks through the failed escapes: object-oriented stores, where "the idea was good the execution was dodgy it was way too early for its time" [3]; XML, which he worked on himself and judges unusable, "typically what happens if peer research people try to define something what a developer has to use" [2]; and the Hadoop wave, where "you get a lot of data in and you never get data out" and his verdict is blunt, "hadoop for me is dead," given S3 buckets and modern databases [2]. JSON succeeded where the others failed because developers actually want it, though he notes the constituencies differ: "developers actually like json bbas love sql business analyst loves sql why because they're used to it," which is why he counts a SQL connector among MongoDB's important pieces [3].

On transactions, ACID and the eventual-consistency temptation

He says he gets challenged on transactions "pretty much every week" and treats it as the load-bearing claim for regulated industries [2]. His account: MongoDB has been ACID compliant since 2015, with 3.2 the real milestone once WiredTiger and audit trails arrived, and since 4.2 it can deliver ACID-compliant transactions across physically distributed shards and multiple collections, so a database split between Australia, China, Russia, London, New York and Tokyo still guarantees the transaction [2]. He also notes people routinely conflate CAP positioning with ACID compliance [2].

He is contemptuous of vendors who wave the requirement away. He recounts being told by a competitor's customer that an eventually consistent credit card transaction reference system was "totally good enough," and that MongoDB's insistence on ACID was "so yesterday," followed eight weeks after deployment by exactly the failures he expected [3]. His position is that the market no longer has to choose: "we need the transactions the assets and the sql and what we call mql" [3]. He frames banking as the hardest possible case, "all of your worst possible nonfunctional requirements, security, transactionality, atomicity" [1].

On efficiency, footprint and sustainability

The Temenos High Water benchmark is his favourite evidence, and what interests him is not the headline throughput but the smallness of the machine underneath it. The run covered 200 million accounts and 100 million customers at 102,875 transactions a second with roughly one millisecond response time, on a full production-grade environment with high availability, security and private links rather than a lab rig [1]. His contribution to the telling is the hardware: "we have a, what we call M80 system in the back, and people look at me, 'You run how many transactions on that one?'" Three quarters of the work was MongoDB, one quarter still elsewhere pending porting, so 75,000 transactions ran on a single 32-core M80. "This is a tiny machine in this world of banking. So before this was a mainframe, and now it's one little instance on AWS," and the conclusion he draws is "Costs are down, and environmental footprint is so, so important" [1]. Doubling throughput on 20% less infrastructure, with up to four times better throughput per core than three years earlier, is presented as a sustainability result as much as a performance one [1].

He also explains why the old benchmark instincts stop applying. In a document database there is no hotspotting a single field of a table; "what goes together, gets stored together, belongs together, comes out together," so IOPS collapse and IOPS stop being a meaningful indicator [1]. Locality of reference and high cache hit rates become irrelevant: "There's no caching in the middle anymore. It goes straight against the database" [1]. He returned to this territory of scale and industry solutions in later conversations about transactions at scale [4].

On availability as a solved expectation

High availability is table stakes and he has moved the bar to continuous availability with no maintenance windows at all: "we have no maintenance windows we have clients running uptime for six years without the blink of an eye rolling updates major release changes" [2]. He cites a group-level CIO at BNP reporting two and a half years of payment operation without a single second of downtime, and treats that, plus consistency and security, as what the business now simply assumes [2]. Cost matters alongside it: with a partner he points to a payment infrastructure handling 100 full payment transactions a second, fully redundant and available 24 by 7, for under 25,000 a year to operate [2].

On real-time transactional data as the point of modernization

He argues data should not be a static blob to be mined later but the substrate of immediate decisions. His example is a lender serving less fortunate borrowers that runs three years of account flows through a behavioural credit profile rather than standard bureau scoring, categorising and scoring each transaction as it arrives and appending around 150 elements to it, all executed by "one single small tiny micro service" with machine learning behind it [3]. The lender told him it saved half a percent of defaults, which he points out "we're talking billions here of default" [3]. He contrasts this with the eight-hour overnight window everyone grew up with [3]. Elsewhere he describes end-to-end real-time as a sensor or e-commerce event landing in the database, being analysed, and a next best offer generated inside 50 milliseconds [2]. The complaint he hears from customers is precisely this gap: "i have my hadoop system but my data are 24 hours old and stale... and i need to pre-compute because otherwise the data don't get ready for the flow" [2].

Latency at the transaction level matters more than people assume. He cites a bank moving payment throughput from five seconds to three milliseconds, and pre-empts the objection: it matters because of the overall time, the support burden and the system infrastructure time around it [2].

On payments becoming a commodity while data becomes the value

He traces payments from 60-dollar SWIFT fees and manual wire rooms handling telex messages, a reality "until some years ago and some years does not mean the 80s that means 2010," to a large France-based bank now running at 0.5 euro cents per transaction [3]. At that price the cost of the transaction stops being interesting, and the bank tells him whether the whole system costs 50 or 60 million over its lifetime is not the issue; stickiness and added value are [3]. So the value migrates upward: "how can i enrich a transaction a transfer of a position with additional knowledge to either enhance the value for the payer or the payee or both and for the bank" [3]. The payload itself has changed with it, since a SWIFT payment that was once payer, payee, bank connection and amount now cannot move "one single dollar" without KYC information [3].

On one platform, no duplication, no lock-in

His architectural preference is a single operational data platform rather than a portfolio of best-of-breed products: one dataset driven through the whole infrastructure, "no data duplication," with analytics on workload-isolated nodes inside the same database, Atlas Online Archive for tiered offload, long-term retirement into the data lake, and search integrated rather than bolted on [2]. Around it sit developer services, serverless functions, charts, a wide range of SDKs and connectors from Kafka and Spark to CDC and BI/SQL, and edge-to-cloud sync with Realm on mobile and devices like Raspberry Pi [2]. Multi-cloud, multi-platform, on-prem and hybrid are the base layer, and the payoff he emphasises is freedom of movement: consolidating gives you "the freedom of how you store your data you can move between the platforms you're not locked into one or the other cloud vendors" [2]. He is scathing about the opposite path, where each cloud's proprietary services trap you, comparing the reassurance that you can always migrate later to an addict's "i can always stop just one more time" [2].

He is careful not to oversell. Not everything moves to MongoDB, and he is candid that "70 to 80 is a realistic number which can be moved quickly," with roughly 20% of legacy left alone [2]. On scale he says he has not seen a limit, with the largest systems he knows around two petabytes, half a petabyte "quite commonly implemented," and 150 to 200 terabyte clients "run-of-the-mill today" [2].

On what business, operations and developers each demand

He splits requirements three ways. The business wants transaction performance, consistency and security, and no longer tolerates two-second round trips [2]. Operations wants robustness and boredom, "they want the vw," a system that runs in any form and shape, cost-effective, with monitoring KPIs to prove SLAs are met [2]. Developers want agile, adaptable programming and elastic compute: "they don't want to think about the sizing up front they don't want to design the solution around the database size instead they want to focus on the code" [2]. Data privacy sits over all of it and has changed character, since a breach is no longer something you absorb, "companies go bankrupt over that one" [2]. The developer path into these skills is also, in his telling, no longer a constraint, given MongoDB University alongside broad market skills [2].

On modernization as a code-reduction exercise

Beyond throughput, he values modernization for what it deletes. Working with Temenos on moving from a relational store back toward the natively hierarchical, XML-shaped internal structures, the gain is cutting out whole backend layers, "because obviously code translation, which was done before, is not needed anymore" [1]. He calls that project "my life experiment" for seeing how long such a transformation really takes [1]. He also acknowledges why firms hesitated historically, that migrations used to be measured in lines of code and length of business freeze, "and that a lot of times led people to say, well, forget it, 'cause business is going to shut down for a year," which he says is no longer the case [1]. The payoff is framed in blunt terms: modernizing rather than shifting is "the difference between, hundreds of millions or billions in some cases versus... some nice little hits here or there" [1]. He ties this to a microservices and API-first posture, and reads the Temenos work as a marker other banks now have to catch up to [1].

Takeaways

• Lift and shift replicates every existing software problem in someone else's data center and adds cloud lock-in; his shorthand is "Shift and lift, pain and no gain" [1][2].
• Expect roughly 70 to 80 percent of an estate to move quickly, with about 20 percent of legacy left alone; he does not claim everything migrates [2].
• SQL the language is fine; the constraint is the table structure people mistake it for, a habit inherited from education rather than physics [3].
• In banking, non-negotiables are ACID across distributed shards, audit trails and security; eventual consistency for a card reference system fails in weeks, not years [2][3].
• Document modelling changes what benchmarks mean: no hotspotting, far fewer IOPS, and no cache layer in front, so 75,000 transactions a second ran on a single 32-core M80 instance where a mainframe used to sit [1].
• Continuous availability is the new bar: no maintenance windows, rolling upgrades, and a BNP payment platform reported at two and a half years without a second of downtime [2].
• Payments themselves are commoditised at fractions of a cent; the value is in enriching each transaction in real time, as with a lender appending about 150 elements per transaction and cutting defaults by half a percent [3].
• Efficiency is a sustainability argument as much as a cost one: double the throughput on 20 percent less infrastructure, up to four times better per core than three years earlier [1].