tidesdb-mysql is an experimental build that was developed to verify how TidesDB, the LSM-tree key/value engine, can work with MySQL 9.7 as a storage engine. The current build is v0.2.4, and it’s an experiment, not a finished product. So you can use it in your tests if you also want to try TidesDB with MySQL … Continued

The post Running TidesDB as a MySQL 9.7 storage engine appeared first on Percona.

A Crunchy to Percona PostgreSQL migration is more straightforward than most cross-operator moves on Kubernetes, because the Percona PostgreSQL Operator is a hard fork of the Crunchy Data PostgreSQL Operator. Same Patroni HA, same pgBackRest backups, same overall CRD shape. This post walks through the safest of the three migration paths: a standby cluster method … Continued

The post Migrate from Crunchy Data PostgreSQL Operator to Percona PostgreSQL Operator: Standby Cluster Method appeared first on Percona.

Overview Servers Tested: MySQL 9.7.0 (PGO-enabled build released by Oracle) MySQL 9.7.0 Non-PGO (built without Profile-Guided Optimization — see BUILD.md) Tier Configurations: Tier 2G: 2GB InnoDB buffer pool Tier 12G: 12GB InnoDB buffer pool Tier 32G: 32GB InnoDB buffer pool   View Results 📊 Interactive Reports The benchmark reports are available as interactive HTML pages … Continued

The post MySQL 9.7.0 PGO Benchmark Analysis appeared first on Percona.

Chess is a lot trickier than it looks. It has so many rules: castling, en passant, pawn promotion, pinning, the discovered check, and the deadlock case of stalemate.

It is a concurrent system, but with a very specific kind of concurrency: interleaved execution. More specifically, taking turns: white, then black, then white.

You know what we do with concurrent systems here? Here we model them, and we distill their invariants.

Here is some setup definitions first.

In a CS or math paper, if you write "Section 2: Model and Problem" well enough, the rest of the paper writes itself. With this setup you can sort of see what the actions will be.

In fact, forget about the actions. Let's look at some invariants.

Invariants

When deriving invariants we ask: what must always be true? I find it useful to split the safety invariants into two camps: state invariants (which are predicates over a single state) and transition invariants (which are predicates over a step). The transition invariants are not as commonly used as state invariants, but they can be very helpful, especially when you are reasoning about transitions of a system.

State invariants

TypeOK says every variable lives in the right space. It is boring, but it has caught more bugs than I would like to admit. OneKingPerColor and BothKingsOnBoard are also sanity checks. 

TurnParity is the first interesting one. It ties two state variables together: WHITE moves on even moves, BLACK on odd. The MakeMove action satisfies this TurnParity.

PreviousPlayerNotInCheck restates the rule that "you must end your turn not in check" as "look back: the player who just moved is not in check". NotBothInCheck is a corollary.

Transition invariants

These are predicates over a <<state, next-state>> pair, written with the bracketed form: [][P]_vars. They express how things change with constraints.  The notation is simple: x is the value of the variable x in this state, and x' denotes the value in the next-state.

MoveCountStrictlyIncreases and TurnAlternates say each step increments the move count with the colors flipping. If a transition ever messes this up, something has gone wrong.

PieceCountNonIncreasing rules out pieces appearing out of thin air. SingleCapturePerMove tightens this: at most one piece disappears per step. ExactlyTwoSquaresChange is the strongest here. It says precisely two squares change per move, the source (now empty) and the destination (now holding the moving piece). 

Haha, yes, this is a model of the basic chess rules only. A useful exercise here is to consider which of these invariants survive when we add castling, pawns, en passant?

ExactlyTwoSquaresChange gets violated when we add castling: four squares change in one move. Similarly, en passant captures a piece not on the destination square, so three squares change.

PieceCountNonIncreasing survives pawn promotion (when a pawn becomes a queen, the count is unchanged).

TL;DR: A bug in MongoDB’s time-series collection code allows a user with the standard readWrite role to corrupt memory within the mongod process. Best case: your database crashes, and you spend the night writing a postmortem. Worst case: an attacker is running their code as mongod, with the same access to your data that the … Continued

The post CVE-2026-8053: “We don’t use time-series” is not a mitigation appeared first on Percona.

Takeaway: Adding foreign keys require schema modification locks on every table involved. This can cause deadlocks on busy systems. Schema modification locks (SCH-M) are taken by DDL (Data Definition Language) statements like CREATE/ALTER/DROP. Schema stability locks (SCH-S) are taken by DML (Data Manipulation Language) statements like INSERT/UPDATE/DELETE. Those two types of locks are incompatible. Meaning, […]

This article explains how to manually migrate hash slots in Valkey/Redis clusters to expand your deployment with minimal disruption to availability. Note: Valkey 9.0 introduces the Atomic Slot Migration (ASM) feature, which significantly improves migration speed (up to 9.52 times faster) and reliability, while reducing migration complexity. So you should use ASM instead if you … Continued

The post Manually Migrate Hash Slots in a Valkey/Redis Cluster appeared first on Percona.

Choosing an open source PostgreSQL operator for Kubernetes used to be a question about features and community size. In 2026, it has become a question about licensing posture, image distribution, and whether the project you pick today will still be operationally open in three years. This is part 1 of a 3-part series on running … Continued

The post Not All Open Source Is Equal: Choosing a PostgreSQL Operator for Kubernetes in 2026 appeared first on Percona.

When the future of pgBackRest suddenly became uncertain, the PostgreSQL ecosystem reacted quickly. At Percona, we believed the most important question was not: what replaces it? but: how do we ensure pgBackRest remains healthy, sustainable, and open for everyone? That distinction matters. pgBackRest is critical infrastructure used by enterprises around the world to protect some … Continued

The post Keeping pgBackRest Open, Healthy, and Community Driven appeared first on Percona.

This is part of our series going through OSTEP book chapters. The OSTEP textbook is freely available at Remzi's website if you like to follow along.

This chapter extends the CPU virtualization playbook to memory. It's the same recipe: let the program run directly on the hardware, but interpose at carefully chosen points so the OS retains control. For memory, this happens at every memory access. Every load, store, and instruction fetch gets translated by hardware from a virtual to a physical address.

The mechanism here is called dynamic relocation, dating to the late 1950s. The base register holds the physical address where the process's address space starts, the bounds register holds its size. On every memory reference the hardware adds base and checks against bounds. If the address is out of range, the CPU raises an exception, and the OS kills the offender.

This takes collaboration between hardware and the OS. Hardware provides privileged mode, the base/bounds registers, translation circuitry, exception generation, and privileged instructions to update the registers. The OS provides memory allocation (a free list, in the simplest case), base/bounds management across context switches, and the exception handlers themselves.

Because there is only one base/bounds pair per CPU, the OS must save and restore them in the process control block(PCB). This means that while a process is descheduled, the OS can freely move its address space and then update the saved base. The process wakes up oblivious to this, hence the name dynamic relocation.

The chapter is transparent about what base-and-bounds gets wrong. The relocated process gets a fixed-size slot, but its stack and heap occupy only a small fraction of it, which means that the space in between causes internal fragmentation. With every process getting the same fat slot regardless of actual footprint, the physical memory fills up quickly. The segmentation discussion, coming next chapter, aims to fix this.

I listened to this book as an audiobook through the Libby app, which basically brings your public library to your phone.

The Thinking Machine is about Jensen Huang and the rise of Nvidia from graphics chips to AI dominance.  The author, Stephen Witt, is a long-form tech journalist. His writing is nice and clear. But it does not have a distinctive voice. I kept thinking of Michael Lewis, whose books have more narrative personality and rhythm.

The book is written for a lay audience. Technical ideas are explained in simplified terms. Much of these were already familiar to me, and I had also lived through Nvidia going from graphics cards to AI chips. (I wish I had bought more stock.)

I was hoping to learn more about Jensen, his philosophy, habits, inner life, management style. There is not much of that in the book. I think that absence is telling. Jensen comes across as a very private person, and almost monastic about work. There does not seem to be a boundary there: he has become one with the work and the company.

The early years were the most interesting to me: young Jensen, finishing college, excelling at AMD, getting married, and the fragile early days of Nvidia. Nvidia was founded at a Denny's in San Jose when Jensen was 30 years old. By 1996 the company was a month from bankruptcy. The first chip had been an architectural dead end, the Sega contract had collapsed, and half the staff was gone. They were betting everything on a single new chip  designed in nine months and verified almost entirely through emulation since there was no time for the usual hardware prototype cycle. No spoilers: it worked, they survived. I think Jensen's resilience, obsession, and inability to let anything go must have been forged in those years. I suspect Jensen's resilience, obsession, and inability to let anything go were forged in those years. And it is hard to ignore that the company that nearly died for lack of simulation went on to make simulation (CUDA, PhysX, Isaac, DRIVE, Omniverse) one of its defining strategic bets.

One recurring theme in the book is what it calls "strategic rage". Jensen publicly criticizes (no berates and yells at) people during meetings. The idea here is that the correction becomes educational for everyone in the room. So Jensen is characterized as giving a harsh lesson and making this a teaching point for others. (Then again, the book also says he shouted at his top-price culinary oven after messing up a recipe. What was strategic about that one?)

So is he an asshole?

I gotta accept, I would feel that way if I were on the receiving end of the yelling (or even in the same room during the yelling). But the picture in the book is more complicated. Jensen does not seem to be driven by cruelty or ego. He doesn't fire people, and tries to educate/elevate them after hiring.

To psychoanalyze the guy from a far, I think he has become one with the work and the mission. He is obsessive, controlling, and emotionally fused with the mission. When the work fails, he reacts viscerally. Apparently even kitchen appliances are not spared.

I found myself oddly sympathetic with Jensen. Maybe because competence is increasingly rare these days. After dealing with enough half-hearted work, incompetent contractors, and people who do not care, I began to deeply value competence. 

Here is a strange example: someone pickpocketed my wallet near the Trevi Fountain in Rome. After the initial shock and the credit-card cancellations, I found myself thinking: this person was unbelievably good at their job. I felt nothing, no bump, no distraction, nothing... The wallet disappeared from the deep front pocket of my jeans like a magic trick. Respect! I remember thinking: if only I were that good/competent at my own work.

That is the feeling Jensen inspires for me. Competence at terrifying scale. Yes, he gets angry and yells in the face of incompetence. But he cares deeply, and he is the hardest worker in the company. I would still work for him. I would want him leading my army.

That temper made the rounds online recently. Jensen went on Dwarkesh Patel's podcast in April, and the middle section turned into a long argument about exporting GPUs to China. Dwarkesh played devil's advocate, channeling Dario Amodei's earlier framing: more compute to China means more risk, especially if a model like Anthropic's Mythos lands there first.

Jensen answered the question. Then he answered it again. Then he answered it a third time from yet another angle. China already has the compute. The 7nm gap is offset by energy abundance and parallelism. Restricting exports just builds Huawei's ecosystem faster (this is exactly what happened when the U.S. ceded telecoms). He made the marginal-sales argument, the CUDA stickiness argument. He laid out a structured case. Eventually, after the same question came back yet again in the same wording, he pushed back hard: "you're not talking to somebody who woke up a loser". The news and people on Reddit seized on this as Jensen losing his composure.

But Dwarkesh dropped the ball there, not Jensen! There might be real holes to pick at in Jensen's case and maybe a case for a competent pushback to move the conversation forward. Instead Dwarkesh kept re-asking the same question in the same wording, leaning on Dario's framing like a script. That was a total failure. A competent interviewer does the homework, identifies the load-bearing claim, and presses on the one place it cracks. Be hard on Jensen, by all means, but bring something. Do not just run the same query against the same response expecting different output. Jensen showed competence in that interview, and he couldn't forgive the total incompetence on Dwarskesh's side. By the way, I was also shouting at Dwarkesh when he kept repeating the same question without listening to Jensen's answers.

Ok, enough said, let's move on...

The most important thing the book communicates is that Nvidia's success was not luck. Jensen saw the importance of parallel computation early and he bet on it more than a decade before the bet paid off. CUDA launched in 2006 as a way to make the GPU programmable for general work, not just graphics. The thesis was that someday someone would need massive parallelism for something other than rendering polygons. Until then Nvidia kept building the toolchain, the libraries, the developer ecosystem, and quietly absorbed the cost. Scientific computing and data analytics were the early adopters, but the market was small and the R&D was very expensive. Wall Street hated CUDA. Activist investors pushed Jensen to kill it. The stock went down. By the late 2000s, the thesis looked like a lost bet.

Then AlexNet happened in 2012, and every machine learning researcher in the world became customers. AI walked into the building Jensen had been constructing for a decade. By the time competitors understood the opportunity, Nvidia had a software moat that hardware alone could not catch.

This part impressed me most: Jensen's conviction on the thesis sustained over decades. He was willing to be misunderstood for more than a decade, because he believed in that thesis. Dwarkesh... bruh, please... fight in your own weight class.