DEV Community: VLAD

Ariane 5, Flight 501: The Exception That Destroyed a Rocket

VLAD — Sat, 10 Oct 2026 21:57:58 +0000

On June 4th, 1996, Europe launched Ariane 5 for the first time. About forty seconds after the flight sequence began, the rocket veered off course, broke up and destroyed itself. The engines were fine. The weather was fine. What failed was a data conversion in code that had no reason to be running.

This story gets retold a lot, usually as "an integer overflow blew up a rocket". The inquiry board's report (chaired by Jacques-Louis Lions, published July 19th, 1996) tells a more useful story. The check actually worked. What nobody had decided was what should happen when it fired.

The box that knows which way is up

To fly straight, a rocket has to know which way it's pointing and how it's moving. On Ariane, that's the job of the inertial reference system, called SRI in the report after its French name. It has laser gyros, accelerometers and its own computer. It sends attitude and velocity data to the main on-board computer, and that computer steers by swiveling the engine nozzles.

Ariane 5 carried two SRIs with identical hardware and identical software. One was active, the other was a hot standby. If the active one failed, the main computer would switch to the backup.

The report also notes that the SRI design, and especially its software, was practically the same as on Ariane 4. It had flown for years. Nobody saw a reason to change software that worked.

Code that had no job

Before launch, the SRI aligns itself: it finds the direction of gravity and finds north from the rotation of the Earth. That only makes sense while the rocket stands still on the pad.

On Ariane 4, the alignment function kept running for a while after the SRI went into flight mode. That was on purpose. If a countdown was held in its last seconds, a full realignment took 45 minutes or more, and the launch window could be lost. Keeping alignment alive a little longer let the team restart the countdown quickly. According to the report, the feature was used once, in 1989.

Ariane 5 had a different preparation sequence and didn't need this. The requirement was kept anyway, to stay in common with Ariane 4. So on Ariane 5 the alignment code ran for about 40 seconds after lift-off, computing values that no longer meant anything.

The number that couldn't get too big

Inside the alignment code there's a value the report calls BH, for horizontal bias. It's related to the horizontal velocity the platform senses. It was held as a 64-bit floating point number, and at one point the Ada code converted it to a 16-bit signed integer. A 16-bit signed integer tops out at 32,767.

The developers knew conversions like this were a risk. The report says they analysed every operation that could raise an exception and found seven variables at risk. But there was a constraint: a maximum workload target of 80% for the SRI computer. So they protected four of the seven conversions. The other three, including BH, were left unprotected, because the reasoning was that those values were either physically limited or had a large safety margin.

For Ariane 4 that reasoning was correct. But:

The justification wasn't in the source code. The report says the assumption, although agreed, was in practice hidden from any external review.
The Ariane 5 trajectory data was not part of the SRI's requirements and specification.
Ariane 5 builds up horizontal velocity about five times faster than Ariane 4 in the early part of the flight.

What happened in flight

The rocket flew normally until about 36 seconds after the start of the main engine ignition sequence. Then BH exceeded what 16 bits can hold. The conversion raised an Operand Error, and nothing in the code handled it.

For an unhandled exception, the SRI specification said: indicate the failure on the databus, store the failure context in memory, and shut the processor down. The report explains where that rule came from. The programme was designed around random hardware failures. If a part breaks at random, you switch the unit off and the backup takes over.

This wasn't random. The backup ran the same software with the same inputs. It had already stopped, one 72-millisecond data cycle earlier, for the same reason. As the report puts it, two critical units that were still healthy got switched off.

Then it got worse. The failed active SRI put a diagnostic bit pattern on the bus, and the main computer interpreted it as flight data. Based on that, it commanded full nozzle deflections on both solid boosters and then on the main engine. The rocket turned at an angle of attack of more than 20 degrees, the boosters started to separate from the core stage, and that correctly triggered the self-destruct system at about 4 km altitude.

The debris fell on about 12 square kilometres of swamp and savanna near the launch site. Both SRIs were recovered, and the failure context was read out of their memory. The four Cluster science satellites on board were lost. The loss is widely reported at about $370 million; that figure is not from the inquiry report.

The same line in C

Here's the part that matters for those of us who will never write flight software. In C#, the same conversion is one cast:

double bh = 40000.0;

short a = (short)bh;            // compiles without a warning
short b = checked((short)bh);   // throws OverflowException

By default, C# evaluates non-constant expressions in an unchecked context. For a double to integer conversion that's out of range, the documentation says the result is an unspecified value of the destination type. No exception, no warning. Your program keeps going with a number that means nothing. In a checked context, the same cast throws OverflowException.

So which one is safer? It's tempting to say "checked, obviously". But Ariane's code was the checked one. The conversion raised the error, and the error is what shut both computers down. The value itself wasn't needed any more. The board points out that the SRIs could have kept providing their best estimates of the attitude data instead.

That doesn't make silent garbage the right answer. It means a check is only half a decision. The other half is what the system does when the check fails: crash, retry, fall back to a safe value, or keep going in a degraded mode. On flight 501, that half had been decided years earlier, for a different kind of failure.

What to take from this

The board made 14 recommendations. Three ideas from the report apply to ordinary code:

Code that isn't needed shouldn't be running. Recommendation R1 is exactly this: switch off the alignment function immediately after lift-off, and more generally, run no software function during flight unless it's needed.
Reused code brings its old assumptions with it. "This value can't get that big" was true for Ariane 4. It wasn't visible in the code, and nobody tested it against Ariane 5's trajectory. The report notes that a ground test with simulated Ariane 5 flight data would have exposed the failure. That test was never run on the SRI.
A backup that runs the same code is no backup against a bug. Redundancy protects you from random hardware faults. Two copies of the same software fail the same way at the same moment.

There's also one position in the report that still sounds bold. The project had treated software as correct until shown to be at fault. The board argued for the opposite view: assume software is faulty until accepted best-practice methods can demonstrate that it's correct.

Ariane 5 recovered. According to ESA, it flew 117 times between 1996 and 2023, and it launched the James Webb Space Telescope. The Cluster satellites were rebuilt and launched in 2000 on Soyuz rockets.

What's the oldest assumption you've found hiding in code you reused? Tell me in the comments.

I make Vlad's Stack, stories and explainers about how the tools you use every day actually work, for people who write code: https://www.youtube.com/channel/UCUO8Uo5LsEy1b9eRkrH6JNg

The Court Order Behind C#: How Two Keywords Started a New Language

VLAD — Tue, 06 Oct 2026 15:09:50 +0000

On November 17th, 1998, a federal judge in San Jose gave Microsoft ninety days to change its Java tools. The court papers in that case talk about two words that C# developers still type every day: delegate and multicast.

This is the story of how a lawsuit over Java ended up producing C#. It's told from the court records, the documents the companies published at the time, and what C#'s lead designer, Anders Hejlsberg, has said in public.

The man from Borland

In the early eighties, Anders Hejlsberg wrote a small, very fast Pascal compiler. Borland sold it as Turbo Pascal. Later, at Borland, he led the team that designed Delphi. In Delphi you drew a window, dropped a button on it, and wrote the code that should run on click.

Keep that button in mind. The whole story turns on one question: how do you connect a button to a piece of your code?

In 1996, Hejlsberg left Borland and joined Microsoft (Artima interview bio). He wasn't the only one to leave. In May 1997, Borland sued Microsoft, saying it had hired away at least 34 of its people in 30 months (EE Times). The two companies settled in September 1997, and the terms were never made public.

Microsoft's Java

In the mid-nineties, Java promised "write once, run anywhere". In March 1996, Microsoft signed a license with Sun Microsystems, the company that owned Java, and built its own Java for Windows: its own virtual machine and a developer tool called Visual J++. Hejlsberg became an architect on Visual J++ and on a Windows library for it, the Windows Foundation Classes (WFC).

Microsoft's Java could call Windows directly. Code that did that only ran on Windows.

Sun sues

On October 7th, 1997, Sun sued Microsoft in federal court in San Jose. The charges included breach of contract, trademark infringement, false advertising and unfair competition (Sun's announcement, via MacTech). Sun said Internet Explorer 4.0 and Microsoft's Java SDK failed Sun's compatibility tests while still carrying the "Java Compatible" logo. It also said pieces were missing: JNI, the standard way for Java to call native code, and RMI, for calling objects on other machines.

Two new words

While the case moved through the court, Microsoft shipped Visual J++ 6.0. Its compiler understood two words that weren't in Java: delegate and multicast.

Here's the problem they solve. A button is written long before your code exists. When someone clicks it, it has to call one of your methods. So you need a way to hand the button a method and say: call this, later.

Java's answer, then, was an object. You wrote a small class that implements a listener interface and passed an instance to the button:

button.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent e) {
        System.out.println("Hello, world!");
    }
});

Microsoft's answer was the delegate: a reference that points straight at a method. You hand over the method itself, like a value. A multicast delegate holds a list of methods, so one click runs all of them.

If you write C#, you use this every day, even if you don't think about it:

button.Click += OnClick;      // add a method to the delegate's list
button.Click += LogClick;     // one click, both methods run

void OnClick(object sender, EventArgs e) => Console.WriteLine("Hello, world!");
void LogClick(object sender, EventArgs e) => Console.WriteLine("clicked");

The court described the J++ version precisely. When Microsoft's compiler met delegate and multicast, it generated classes that extend com.ms.lang.Delegate and com.ms.lang.MulticastDelegate, classes that only Microsoft's virtual machine had. The bytecode was valid, but it looked for classes no other JVM shipped (Sun v. Microsoft, 21 F. Supp. 2d 1109).

Sun says no, for the second time

Sun's Java team answered with a public white paper, "About Microsoft's 'Delegates'". It argued that bound method references were unnecessary and bad for the language, and that inner classes could do the same job.

Then it said something surprising. Sun had considered this exact idea in 1996. It had built working prototypes and thrown them away. And it made that decision in consultation with Borland, which already had bound method references in Delphi.

Delphi, the language Hejlsberg had led at Borland. The idea Sun turned down in 1996 was back, inside Microsoft's Java.

Ninety days

On November 17th, 1998, Judge Ronald Whyte granted Sun a preliminary injunction. Microsoft had ninety days to:

ship a Java runtime that supports JNI and passes Sun's tests;
make its compiler disable the Microsoft language extensions by default;
show a warning when a developer turned them on, saying the code might not run on other Java virtual machines;
and stop adding any new keywords or compiler directives to its Java tools.

Hejlsberg himself filed a declaration in the case. A later order cites it to explain that WFC, his Windows library, used the delegate and multicast keywords (87 F. Supp. 2d 992, Jan 2000).

While that order stood, Microsoft's Java couldn't get a single new language feature. The case went to the Ninth Circuit and back, and a new order came in January 2000. But Visual J++ 6.0 was the last version.

Project Cool

Around the start of 1999, Hejlsberg put together a small team to design a new language. Its working name was Cool, for "C-like Object Oriented Language". He has said the core design team was about six people, meeting three times a week for two hours (The Pragmatic Engineer). In 2001, he described the goal as the power and expressiveness of C++ with the ease of Visual Basic (CNET interview, via HPCwire).

This time, nobody else owned the language. Microsoft could add any keyword it wanted. So delegates went in, not as an extension but as a core part of the language. Multicast went in too, built into every delegate. And on top of it came a new keyword, event. Properties, events and a button wired straight to a method were built into the language from day one.

C# ships

June 26, 2000: Microsoft announced C# and submitted it to the standards body ECMA. An early preview followed at the Professional Developers Conference in Orlando, on July 11.
January 23, 2001: the Java case settled. Microsoft paid Sun $20 million, the 1996 license was terminated, and Microsoft could keep shipping its existing Java products for seven years.
December 2001: ECMA approved ECMA-334, the C# standard, based on a submission from HP, Intel and Microsoft.
February 13, 2002: Bill Gates launched .NET and Visual Studio .NET. C# shipped with them.

The twist

In April 2004, the two companies made peace. Microsoft paid Sun $700 million to settle antitrust issues and $900 million for patents (Microsoft announcement). Microsoft's Java virtual machine was retired for good at the end of 2007.

And Java? In 2014, Java 8 added lambdas and method references, so you could finally hand a button a method directly:

button.addActionListener(this::onClick);

It isn't the same thing as a C# delegate under the hood (Java still compiles it to an object that implements a functional interface). But it solves the problem Sun's white paper had called unnecessary.

Why C# exists

Microsoft wasn't allowed to change a language it didn't own, so it built one it could change. The next time you write += on an event, remember that the feature behind it was once at the center of a federal court case.

If Sun had said yes to delegates in 1998, would C# exist at all? Tell me what you think in the comments.

I make Vlad's Stack, stories and explainers about how the tools you use every day actually work, for people who write code: https://www.youtube.com/channel/UCUO8Uo5LsEy1b9eRkrH6JNg

Knight Capital: How One Forgotten Server Lost $440 Million in 45 Minutes

VLAD — Mon, 28 Sep 2026 21:51:50 +0000

On August 1st, 2012, Knight Capital lost more than $400 million in about 45 minutes. It wasn't a hack or a bad bet. It was old code that nobody remembered was still running on one of eight servers.

Everything below comes from the official record: the SEC order against Knight Capital (Release No. 34-70694, October 2013). It reads like a postmortem, and most of its lessons apply far outside finance.

The machine: parent orders, child orders, and a counter

Knight handled about one in ten trades in U.S. listed stocks in 2011–2012. One of its core systems was SMARS, an automated router. It took a big "parent" order, split it into smaller "child" orders, and sent those to exchanges.

The key part was a counter. SMARS tracked how many shares of the parent order had already been filled, and stopped sending children when the order was complete. Remember that counter.

The ghost in the code

Inside SMARS lived an old feature called Power Peg. Knight stopped using it in 2003, but the code was never deleted. It stayed on the servers, still callable.

In 2005, the counter that told Power Peg when to stop was moved to a different place in the code. Power Peg was never retested after that. Nobody checked whether it still knew when to stop. It didn't.

In 2012, the NYSE launched a new retail program starting August 1st, and Knight wrote new code for it. The new code needed a switch, a flag on each order that meant "use the new feature". Instead of adding a new flag, it reused the old flag that used to activate Power Peg. The plan was to replace the old code everywhere, so the flag would simply mean something new.

The deploy: seven out of eight

SMARS ran on eight servers. Starting July 27th, a technician copied the new code to them by hand over several days. Seven servers got it. The eighth didn't, so it still had Power Peg.

There was no second person reviewing the deployment, and no written procedure requiring one. Other teams at Knight had written procedures; the SMARS team didn't.

97 warnings nobody read

At 8:01 a.m., before the market opened, a Knight system started emailing a group of employees about SMARS orders with the error "Power Peg disabled". By 9:30 it had sent 97 of them. They weren't designed as alerts, and nobody generally read them. They named the exact problem.

9:30: 212 orders become millions

When the market opened, orders arrived carrying the reused flag. Seven servers ran the new code. The eighth ran Power Peg, which kept sending child orders because its counter wasn't where it expected. Another part of Knight's system knew the orders were filled, but that information never reached SMARS.

212 customer orders turned into millions of child orders: about 4 million executions in 154 stocks, over 397 million shares.

People inside saw positions piling up in one account with a $2 million limit. But the risk tool only displayed numbers to humans. It wasn't connected to the order system, it didn't raise automated alerts, and nothing cut the machine off.

The fix that made it worse

The engineers reasoned that the trouble started with the new code, so they removed it from the seven servers where it was working. The orders still carried the reused flag. Now all eight servers woke up Power Peg.

The bill

When it stopped, Knight held about $3.5 billion of stock it never wanted to buy and had sold about $3.15 billion it didn't own. Knight first estimated the loss at about $440 million; the SEC later put it at over $460 million. In 37 stocks, prices moved more than 10% with Knight doing most of the trading.

Five days later, investors put in $400 million to keep the firm alive. Less than a year later it merged with a rival. The SEC fined it $12 million for not having the controls the market access rule requires.

What a developer should take from this

None of the individual decisions looked dangerous on the day they were made. That's the point.

Delete dead code. Code that's switched off is still code that can be switched on.
One flag, one meaning. Give every new feature its own flag, and plan the day you'll remove it. Reusing a flag makes old code reachable in ways nobody is thinking about.
Verify every deploy. Automate it, and make every instance report which version it runs. The eighth server can't hide from a script.
Build the kill switch before you need it. If your code can spend money or send messages at machine speed, stopping it must not depend on first understanding the bug.
An alert nobody reads is not an alert. If a message can say "Power Peg disabled" 97 times without anyone noticing, it's noise, and noise hides the one message that matters.

What's the oldest dead code you've ever found in production?

I make Vlad's Stack — how the tools you use every day actually work, for people who write code: https://www.youtube.com/@VladsStack

Embeddings explained for people who write code

VLAD — Fri, 18 Sep 2026 22:08:01 +0000

Type "how do I reset my password" into a good search box, and it finds a page titled "account recovery." Zero words in common. Nothing matched on text. So how did it know they mean the same thing?

Your app turned meaning into numbers — and once meaning is numbers, a computer can measure it. That trick is called an embedding. Get this one idea and half the AI buzzwords — "vector search," "cosine similarity," "vector database" — stop being scary.

Prefer to watch? Full walkthrough with the meaning-space animation:

An embedding is a list of numbers

Start with the machine itself. You hand it a piece of text — a word, a sentence, a whole paragraph. It hands back a list of numbers. That list is the embedding. Same text in, same numbers out, every time.

How long is the list? For a common model — OpenAI's text-embedding-3-small — it's 1,536 numbers. That sounds like a lot, until you think of each number as a coordinate.

Two numbers place a point on a map. Three place it in a room. 1,536 place it in a space you can't picture — but the math works exactly the same as the map.

Meaning becomes position

Here's the whole point of that space: the model places text so that similar meaning lands in a similar spot. "cat" and "dog" end up as neighbors. "car" ends up far away.

Nobody wrote that rule. The model learned it — it read a mountain of text and noticed which words keep the same company. Words used the same way get pushed together; words used differently get pushed apart. This is an old idea from linguistics called the distributional hypothesis: a word's meaning is shaped by the words it usually appears next to. Meaning, in this space, is just where you land relative to everything else.

"Cosine similarity" is just an angle

Now the real question in search: are these two things close? You embed the question, you embed every document, and you grab the points nearest the question. But "nearest" means one specific thing — and it's simpler than it sounds.

Draw an arrow from the center of the space out to each point.

Two texts with similar meaning? Their arrows point almost the same way — a small angle between them.
Unrelated texts? The arrows point off in different directions — a wide angle.

That angle is cosine similarity. A value near 1 means the arrows point the same way (very similar). A value near 0 means they're unrelated. That's the whole comparison — "cosine similarity" is just measuring the angle between two arrows.

In code, it's three lines

Every "AI search" feature you've used is basically this, under a nicer name:

const doc   = embed("account recovery steps")      // → [0.02, -0.91, …] · 1536 numbers
const query = embed("how do I reset my password?")

// cosine: 1 = same direction, 0 = unrelated
const score = cosine(query, doc)                   // ≈ 0.86 — close

Embed your text, embed your query, compare them, keep the closest. (Those scores are illustrative — the real point is high = same direction.)

Trap 1: the numbers only make sense inside one model

These coordinates are only meaningful within a single model. A vector from model A and a vector from model B are not comparable — it's gibberish. Same coordinates, different maps.

So embed your query and your documents with the exact same model, always. Change the model, and you have to re-embed everything you're searching over.

Trap 2: embeddings capture meaning, not exact strings

Embeddings are great at meaning — which makes them bad at things that have no meaning. An error code. A product ID. SKU-4417. There's nothing to place on the meaning-map; it's just an exact string, and pure vector search fumbles it, because nothing is "close in meaning" to a serial number.

That's why real systems run both: keyword search to catch exact strings, vector search to catch meaning, and the results merged. If you've built RAG and watched it miss an obvious error code, this is usually why.

The takeaway

An embedding, start to finish:

Text becomes a list of numbers.
The numbers are coordinates in a meaning-space.
Close in meaning → close in space.
"Similarity" is just the angle between two arrows.

Once you see it as numbers on a map, the buzzwords fall away — and you can actually debug your search instead of trusting it. When a result looks wrong, you're not staring at magic; you're asking a concrete question about distance on a map.

What's the weirdest match your vector search ever returned — the one that made no sense at all? Drop it in the comments — I read them.

I make Vlad's Stack — how the tools you use every day actually work, for people who write code. Full video walkthrough is above.

SQL vs. NoSQL — stop asking the wrong question

VLAD — Mon, 07 Sep 2026 00:37:44 +0000

Two teams build the same app. One picks SQL. One picks NoSQL. Six months later, one team is rewriting their whole data layer — and it's not because they picked the wrong database. It's because they asked the wrong question.

Everyone fights about which one is faster, or which one scales. That's the wrong fight. By the end of this you'll know the one question that actually decides it, and why three things you've heard about SQL and NoSQL are just wrong.

Prefer to watch? Full walkthrough with the JOIN-vs-document animation:

The wrong question

"Which one is faster?" "Which one is modern?" "Which one scales?"

None of these pick your database. Speed and scale depend on how you use a database, not on which logo you chose. You can make either one fast, and you can make either one fall over.

The right question

What shape is your data — and how will you read it back?

Answer that, and the database almost picks itself. Here's what that means.

SQL: a relational database

In SQL, your data lives in tables — rows and columns, like a spreadsheet with rules. You define the shape up front. That's the schema.

The superpower is the JOIN. You keep users in one table and orders in another, then stitch them together on the fly to answer almost any question:

SELECT u.name, count(o.id)
FROM users u
JOIN orders o ON o.user_id = u.id
GROUP BY u.name;

"Every user, and how many times they ordered." You never designed for that query — SQL answers it anyway. That flexibility is the whole point of a relational database.

But it has a price. Your data is split across tables (that's normalization), so to read one thing back, the database has to stitch those tables together on every read. Fine at normal size. So what does NoSQL do differently?

NoSQL isn't one thing

First, an important correction: NoSQL isn't a single kind of database. It's a family. The four categories you'll usually see are document, key-value, wide-column, and graph databases.

They share one idea: you model your data around how you read it. Store together what you read together.

So instead of separate users and orders tables, you store one document — the user, with their orders inside it:

{
  "name": "Vlad",
  "orders": [
    { "id": 1, "total": 40 },
    { "id": 2, "total": 15 }
  ]
}

One read. Nothing to stitch. It's already assembled.

Same question, two shapes

That's the core difference. Ask "give me this user and their orders":

SQL joins two tables at read time.
NoSQL hands you a document that was already built that way.

Same answer, different shape. And that's the whole trade. The document is faster — for the read you planned. But now ask a new question: "every order over $40, across all users." In SQL that's one line. In your documents, that data is buried in a thousand separate places, because you didn't store it that way.

That's the trap that kills projects. You pick the shape for today's question. Then the product grows, the questions change — and the shape can't. That's the team rewriting everything.

Three myths, killed

Three things you've probably heard push people toward the wrong choice.

Myth 1 — "NoSQL has no schema"

False. The schema didn't disappear — it moved into your application code. Every read still assumes a shape; you just gave up the database checking it for you.

This even has a name: schema-on-read. As Martin Fowler puts it, a "schemaless" store still has an implicit schema — the structure your code relies on when it reads the data — instead of an explicit one enforced by the database. "Schemaless" doesn't mean no schema. It means you own it now.

Myth 2 — "SQL can't scale"

Also false. Postgres runs massive production workloads, and you'll hit product problems long before it's your bottleneck. And when you genuinely outgrow a single node, distributed SQL exists now — CockroachDB, Google Cloud Spanner, and Vitess all give you horizontal scale without giving up SQL.

Myth 3 — "NoSQL is faster"

Only for the pattern it was built for. Ask it something off-pattern and it's slower — or it just can't answer without loading everything and filtering in your app. Fast isn't a property of the database. It's a property of the match between your data's shape and your query.

So when do you use each?

Relationships that matter, and questions that will change → go relational (SQL).
One known access pattern, at huge scale → that's where NoSQL wins.
And you're allowed to use both — plenty of systems put a relational database next to a key-value cache or a document store, each for what it's good at.

For most apps starting out, the boring answer is the right one: start with Postgres, and reach for NoSQL when you have a real, specific reason — not a vibe.

The takeaway

Stop asking which one is better. Ask what shape your data is, and how you'll read it back — and the database picks itself.

What made you reach for NoSQL last time — the scale, or the schema? Drop it in the comments — I read them.

I make Vlad's Stack — how the tools you use every day actually work, for people who write code. Full video walkthrough is above.

What actually happens in a database index (and why half of them do nothing)

VLAD — Sat, 05 Sep 2026 21:25:42 +0000

Same query. Same table. Same million rows. One day it takes 4 seconds. The next day, 4 milliseconds. Nothing changed in the data. The only thing that changed was one line — you added an index.

Four seconds to four milliseconds is a thousand times faster, from one line of SQL. But here's the part nobody tells you: half the indexes people add do nothing. The query stays slow, the writes get slower, and they can't figure out why.

By the end of this you'll know what an index actually is — and the one rule that decides whether yours even gets used.

Prefer to watch? Full walkthrough with the B-tree lookup animation:

With no index: a full table scan

You ask the database for one user by email. With no index, what does it do?

It reads the first row. Not a match. The second row. Not a match. It keeps going — every single row — until it finds yours or runs out. A million rows, a million checks.

SELECT * FROM users
WHERE email = 'vlad@stack.dev';

With no index, that WHERE line has only one way to run: look at all of them. The work grows with the table — ten times the rows, ten times the wait. That's a full table scan, and that's your four seconds.

What an index actually is

Most people picture an index as a copy of the table, or some kind of cache. It's neither.

An index is a sorted map — just the column you search on, kept in order, with a pointer back to the full row. And the shape it's sorted into has a name: a B-tree (the default index in both Postgres and MySQL — technically a B+ tree).

At the top, one node — the root.
It splits into a few branches.
Each branch splits again, down to the leaves, where the pointers to the rows actually live.

Every node is sorted. The root doesn't hold your data — it holds signposts. Emails before "M"? Go left. "N" and after? Go right. Each step throws away half the tree, or more. You're never reading rows. You're following signs.

The walk: three hops, not a million rows

Watch what the lookup actually does:

The root — one hop.
A branch — two.
A leaf — found.

Three hops. Not a million rows. Three.

That's the whole trick. A scan checks every row — that's the four seconds. A B-tree walk checks a handful — that's the four milliseconds. Grow the table to ten million rows and the scan gets ten times worse, while the tree adds one more hop. That's O(n) versus O(log n).

So why not index everything?

Because an index is not free. It's a second structure the database has to keep in sync. Every time you insert a row, change that column, or delete one, the tree has to be updated too.

Index the whole table, and your reads fly while your writes crawl.

So an index is a trade: faster reads, slower writes, more disk. You pay it on purpose — on the columns you actually search — not on all of them.

The trap: an index your query can't use

Here's the part that trips everyone up. You add the index. The query is still slow. How?

Because an index only helps if your query can actually use it — and it's shockingly easy to write one that can't.

The phone-book rule

Say you index two columns together — last name, then first name:

CREATE INDEX ON users (last_name, first_name);

Search by last name? Fast.
Search by last and first? Fast.
Search by first name alone? Scan.

The tree is sorted by last name first, so first name is useless without it. It's a phone book: perfect for finding "Smith," useless for finding every "John." This isn't a quirk of one database — B-tree indexes everywhere work left to right, or not at all.

Three more ways to quietly kill an index

Leading wildcard: email LIKE '%dev' starts with a wildcard, so the tree can't seek — it scans.
Function on the column: wrap it in lower(email) and your index on plain email doesn't match.
Low selectivity: index a column that's half true, half false, and the database ignores it — a signpost that splits nothing saves nothing.

The takeaway

An index is a sorted B-tree. It turns a full scan into a three-hop walk — but only if your query matches the way it's sorted. The order of the columns isn't a detail. It is the index. Get that order wrong, and you built a tree the query will never climb.

What's the slowest query you've ever fixed with a single index? Drop it in the comments — I read them.

I make Vlad's Stack — how the tools you use every day actually work, for people who write code. Full video walkthrough is above.

Why more context makes your AI answers worse

VLAD — Mon, 31 Aug 2026 22:16:08 +0000

Your model says it has a one-million-token context window. Its real working memory is a lot smaller than that.

On long-context benchmarks, models start failing well below the number printed on the box. And here's the part nobody warns you about: past a certain point, adding more context makes your answers worse. Not better. Worse.

Prefer to watch? Full walkthrough with the attention-cost animation:

A context window is not memory

Let's kill one idea first. A context window is not memory.

The model doesn't remember your last message — it's stateless. It keeps nothing between calls. Every single call, you send the whole conversation again. All of it.

Look at what you actually ship over the wire:

Turn one: a system prompt and one question. Small.
Turn ten: the same system prompt, plus nine questions, plus nine answers, plus the new one.

The window is just how much text fits in that box before the API says no. And everything in the box gets processed. Every time.

What attention actually does

Inside the model, attention has a job that's simple to say: every token looks at every other token and decides how much it cares about each one.

10 tokens → 100 pairs
1,000 tokens → 1,000,000 pairs
100,000 tokens → 10,000,000,000 pairs

Ten times the context isn't ten times the work. It's a hundred times the work. (That's just arithmetic: cost grows with the square of the input.)

That's also why the first reply in a long chat feels slow and the rest feel fast — the model caches the keys and values it already computed. But the cache saves you compute. It doesn't save your answer quality. That's a separate problem, and it's the one you actually feel.

Here are the three reasons big context hurts.

Reason 1 — attention is a budget

For every token, the attention weights add up to one. Always one — that's what softmax does.

So when you paste in fifty more documents, you don't hand the model more focus. You split the same focus into more pieces.

Think about search on your laptop. One folder, ten files — you find it in a second. Same search, ten thousand files, same query, and the right file is now somewhere on page four. The model has that exact problem. Except it never shows you page four. It just answers.

Reason 2 — lost in the middle

Researchers took one correct answer and moved it around inside a long prompt. Same prompt, same question, different position. Then they measured accuracy.

Near the beginning: good.
Near the end: good.
In the middle: much worse.

(Liu et al., Lost in the Middle.) So your most important paragraph, sitting at 60% of a long prompt, is in the worst possible spot in the whole file.

Reason 3 — distractors in your own data

This is the one I hit most in real code. The famous needle-in-a-haystack test is easy, because the needle looks nothing like the hay. Your production data is not like that.

You've got version two of the doc. Version three. An old changelog. And a chat thread that contradicts all three. Four chunks that all look right. One of them is right — and the model can't tell which.

It gets worse as the input grows: accuracy drops steadily with input length, even on tasks the same model nails at short length. So the number on the box tells you what fits. It doesn't tell you what works.

Four things you can actually change

1. Send less, but better. If you're doing retrieval, stop pushing the top fifty chunks into the prompt. Search wide, re-sort the results, then send the top three to five. Fewer clean chunks beat more chunks, every time.

2. Use the edges. Instruction at the top. Data in the middle. Then repeat the actual question at the bottom, right before the model answers. That last line costs you nothing, and it works.

3. Stop reusing one giant thread. Split the job into steps. Each step gets a fresh, small context with only what it needs. Between steps, pass a short summary — not the full transcript. That's most of what agent frameworks are doing for you under the hood.

4. Measure it on your own data. Take twenty real questions from your app. Run them with 2,000 tokens of context, then run the same twenty with 20,000. Compare the answers side by side. You'll find your own limit — and it'll be lower than the spec sheet.

The takeaway

The context window is a hard limit on what fits. It was never a promise about what the model can use. Treat it like bandwidth you're paying for, and send the smallest thing that answers the question.

What's the biggest prompt you've ever shipped to production? And when you cut it down, did it get better or worse? Tell me below.

I make Vlad's Stack — how the AI tools you use every day actually work, for people who write code. Full video walkthrough is above.

Why your RAG returns garbage (and it's not the model)

VLAD — Mon, 31 Aug 2026 22:12:03 +0000

Your RAG bot just gave a confident, detailed answer. And it's completely wrong.

Here's the part that'll annoy you: the model did nothing wrong. It answered perfectly — using the text you handed it. The bug isn't in the AI. It's in the five steps before the AI.

Prefer to watch? Full 6-minute walkthrough with the "lost in the middle" animation:

The pipeline, in one line of code

RAG is simple on paper. You search your own documents, grab the best matches, paste them into the prompt, and the model answers from those. So when the answer's garbage, everyone blames the model.

Wrong suspect. There are five places this pipeline breaks — and four of them happen before the model even runs:

const chunks  = split(docs)                   // 1 · chunking
const vectors = embed(chunks)                 // 2 · embedding
const hits    = search(embed(query), vectors) // 3 · retrieval
const best    = rerank(query, hits)           // 4 · ranking
const answer  = llm(prompt(best, query))      // 5 · generation

Five lines. Every bug I'm about to show you lives on one of them.

1. Chunking — a fixed cut splits your answer in half

Your documents are long, so you cut them into pieces before you store them. Most people cut every few hundred characters and move on. That's where it starts to rot.

A fixed-length cut doesn't care about meaning. It'll slice a sentence in half. It'll split a question from its answer. Now the one chunk that held your answer is two halves — and each half looks irrelevant on its own. So retrieval never even finds it.

Fix: cut on structure, not length. Split on paragraphs and headers — where the meaning actually breaks. And let chunks overlap a little, so nothing gets stranded at the edge.

2. Embedding — your question doesn't look like its answer

Every chunk goes through a model that turns text into a vector: a long list of numbers that captures its meaning. Similar meaning, similar numbers. That's the whole trick that makes search work.

But here's the trap. Your question gets embedded by the same model — and a question rarely looks like its answer.

You ask "how do I reset my password?" The doc says "account recovery procedure." Same thing to a human. Different words — and a weak embedder puts them far apart.

Fix: pick an embedding model built for retrieval, and test it on your data. A model that's great on legal text can be useless on code.

3. Retrieval — vector search fumbles exact strings

You take the question's vector and grab the closest chunks. This is the "vector search" everyone talks about. On its own, it's got a blind spot.

Vector search matches meaning, not exact words. Which is great — until someone searches for an error code. A product name. SKU-4417. Those barely have a meaning to embed. They're just exact strings, and nothing is "close in meaning" to a serial number.

Fix: hybrid search. Run keyword search and vector search, then merge the results. Old-school keyword matching catches the exact strings embeddings miss.

4. Ranking — the best chunk was #8, and you dropped it

Now you've got a pile of candidates — say the top twenty. But you can't paste twenty chunks into the prompt, so you keep the top five and drop the rest.

Here's the question nobody asks: what if the best chunk was ranked number eight? Then you just threw it away. Your answer was in the pile, and you cut it.

Fix: a re-ranker — a second, smarter model that reads the question and each chunk together and re-scores them. Cheap vector search casts a wide net; the re-ranker picks the real winners out of it. Now your top five are actually the top five.

And order matters too — "lost in the middle"

Even the order you paste chunks in changes the answer. Models pay the most attention to the start and the end of the context. Put your most important chunk in the middle, and the model can skim right past it.

This isn't a hunch — it's measured. The same model gets more accurate just by moving the right chunk to the edges of the context (Liu et al., Lost in the Middle, 2023). So put your best chunk first, or last. Never buried in the middle.

5. The prompt — where people ruin it two ways

Right chunks, right order. This is your last chance to ruin it, and people do it two ways:

They dump in everything. Ten thousand tokens of maybe-relevant text, hoping the model sorts it out. More context isn't more accuracy — it's more noise to get lost in.
They never tell the model what to do when the answer isn't there. So it does the one thing you don't want: it makes something up.

Fix is basically one line in your prompt:

"Answer only from the context below. If it's not there, say you don't know."

That single instruction turns a confident liar into a system you can trust. A RAG bot that admits "I don't know" beats ten that guess.

Put the blame where it belongs

Bad chunks
Wrong embedder
Vector-only search
No re-ranker
A sloppy prompt

Five failure points — and notice the model was the last one. Usually the innocent one.

So next time your RAG bot lies to you, don't touch the model first. Walk the five steps backward — prompt, ranking, retrieval, embedding, chunks. The bug is almost always upstream.

What's the worst answer your RAG bot has ever given you? Drop it in the comments — I actually want to read those.

I make Vlad's Stack https://www.youtube.com/channel/UCUO8Uo5LsEy1b9eRkrH6JNg — how the AI tools you use every day actually work, for people who write code. Full video walkthrough of this one is above.

What a Linux container really is (it's not a VM)

VLAD — Mon, 31 Aug 2026 22:10:38 +0000

Right now, on your machine, a process is being lied to.

It thinks it's alone on the computer. It thinks it owns the whole filesystem. It thinks its process ID is 1. None of that is true. It's running right next to everything else, on the same kernel — and the kernel is lying to its face.

That lie has a name. We call it a container.

Prefer to watch? Full 6-minute walkthrough with the animation:

There is no "container" in the kernel

Here's the first thing nobody tells you. Open the Linux kernel source, search for a thing called a "container." You'll find zero. There is no container object. The kernel has no idea what the word means.

So what are you actually running? A normal process. The same kind as your text editor. Just with a few settings flipped. Docker doesn't build a magic box around your app — it starts a plain process and flips those settings for you.

There are two settings that do all the work:

The first controls what the process can see.
The second controls what it can use.

That's the whole magic. See, and use.

Trick 1 — namespaces (what a process can see)

Normally every process on the machine shares one view of the world: the same list of process IDs, the same filesystem, the same network. A namespace hands one process its own private copy of that view.

Put it in a PID namespace, and it sees itself as process 1 — like the machine just booted for it.
Put it in a mount namespace, it gets its own filesystem root.
Give it a network namespace, and it has its own network interface and its own IP.

So on the real host, your process might be number 842, sitting in a list of hundreds. Inside its namespace, it looks down and sees... 1. Same machine, same kernel. The process just can't see past the wall the kernel drew around it.

root inside, nobody outside

Here's the detail that trips everyone up: there's a user namespace too.

Inside the container, your process can be root — user zero, full power. Outside, on the host, that same process is a boring, unprivileged user.

Root on the inside. Nobody on the outside. Same process. That's namespaces doing their job — and it's the foundation of rootless containers.

Trick 2 — cgroups (what a process can use)

Namespaces decide what you see. The second trick decides what you get. It's called a cgroup — a control group.

A cgroup sets limits. This process gets two CPU cores, not all of them. Half a gig of memory, and not a byte more. Cross the memory limit? The kernel kills it on the spot (that's your OOM kill).

That's how one container can't starve every other one on the box. No limits, and one noisy app eats the whole machine.

The whole idea in one line

Namespaces are what you see. Cgroups are what you get.

A container is just a normal process wrapped in those two things. Nothing else is in the box — because there is no box.

Why it's not a virtual machine

This is the part people get wrong the most.

A virtual machine boots its own kernel, on fake hardware that a hypervisor pretends is real. A whole operating system, from scratch, every time.

A container has no kernel of its own. It borrows the host's kernel — the one that's already running.

That one difference explains everything:

Speed. No kernel to boot means a container starts in milliseconds, where a VM takes seconds.
Isolation. Sharing a kernel cuts both ways. One kernel bug can let a process break out of its container and onto the host. A VM doesn't share that wall.

So you're trading isolation for speed. That's the deal — and it's a fair one, as long as you know you're making it.

Build one by hand — no Docker

Don't believe there's no magic? Build a "container" yourself with two commands:

# a "container" with no Docker at all
unshare --pid --mount --net --uts --fork \
  chroot ./rootfs \
  /bin/sh

unshare flips on the namespaces.
chroot swaps the root filesystem.
And you're dropped into a shell that thinks it's alone on a fresh machine.

No daemon, no image — just kernel features.

So what does `docker run` actually do?

Four steps, in pseudo-code:

unpackImage(image)        // files become the new root
applyNamespaces(process)  // its own PID, mounts, network
applyCgroups(process)     // capped CPU and memory
exec(process)             // now it's just... a process

Unpack the files. Wrap it in namespaces. Cap it with cgroups. Run it. That's the whole thing Docker does that felt like magic.

And the image everyone ships around? It's just a stack of files in a tarball, plus a little metadata saying which program to start. No operating system inside. No kernel inside. Just files.

One number to leave you with

The Linux manual page namespaces(7) lists eight separate kinds of namespace — eight different views the kernel can hand a single process: mount, PID, network, IPC, UTS, user, cgroup, and time. That's the whole toolbox a container is built from.

So next time someone draws a container as a little box floating above the machine — remember there's no box. There's your kernel, showing one process a smaller version of the truth. Namespaces for what it sees, cgroups for what it gets, one shared kernel underneath.

What did you think a container was, before this? Tell me in the comments.

I make Vlad's Stack https://www.youtube.com/channel/UCUO8Uo5LsEy1b9eRkrH6JNg — how the tools you use every day actually work, for people who write code. Full video walkthrough of this one is above.

Why more context makes your AI answers worse

VLAD — Mon, 31 Aug 2026 22:09:07 +0000

Your model says it has a one-million-token context window. Its real working memory is a lot smaller than that.

Prefer to watch? Full walkthrough with the attention-cost animation:

A context window is not memory

Let's kill one idea first. A context window is not memory.

The model doesn't remember your last message — it's stateless. It keeps nothing between calls. Every single call, you send the whole conversation again. All of it.

Look at what you actually ship over the wire:

Turn one: a system prompt and one question. Small.
Turn ten: the same system prompt, plus nine questions, plus nine answers, plus the new one.

The window is just how much text fits in that box before the API says no. And everything in the box gets processed. Every time.

What attention actually does

Inside the model, attention has a job that's simple to say: every token looks at every other token and decides how much it cares about each one.

10 tokens → 100 pairs
1,000 tokens → 1,000,000 pairs
100,000 tokens → 10,000,000,000 pairs

Ten times the context isn't ten times the work. It's a hundred times the work. (That's just arithmetic: cost grows with the square of the input.)

Here are the three reasons big context hurts.

Reason 1 — attention is a budget

For every token, the attention weights add up to one. Always one — that's what softmax does.

So when you paste in fifty more documents, you don't hand the model more focus. You split the same focus into more pieces.

Reason 2 — lost in the middle

Researchers took one correct answer and moved it around inside a long prompt. Same prompt, same question, different position. Then they measured accuracy.

Near the beginning: good.
Near the end: good.
In the middle: much worse.

(Liu et al., Lost in the Middle.) So your most important paragraph, sitting at 60% of a long prompt, is in the worst possible spot in the whole file.

Reason 3 — distractors in your own data

This is the one I hit most in real code. The famous needle-in-a-haystack test is easy, because the needle looks nothing like the hay. Your production data is not like that.

Four things you can actually change

2. Use the edges. Instruction at the top. Data in the middle. Then repeat the actual question at the bottom, right before the model answers. That last line costs you nothing, and it works.

The takeaway

The context window is a hard limit on what fits. It was never a promise about what the model can use. Treat it like bandwidth you're paying for, and send the smallest thing that answers the question.

What's the biggest prompt you've ever shipped to production? And when you cut it down, did it get better or worse? Tell me below.

I make Vlad's Stack https://www.youtube.com/channel/UCUO8Uo5LsEy1b9eRkrH6JNg — how the AI tools you use every day actually work, for people who write code. Full video walkthrough is above.

Why more context makes your AI answers worse

VLAD — Mon, 31 Aug 2026 21:42:30 +0000

Your model says it has a one-million-token context window. Its real working memory is a lot smaller than that.

Prefer to watch? Full walkthrough with the attention-cost animation:

A context window is not memory

Let's kill one idea first. A context window is not memory.

The model doesn't remember your last message — it's stateless. It keeps nothing between calls. Every single call, you send the whole conversation again. All of it.

Look at what you actually ship over the wire:

Turn one: a system prompt and one question. Small.
Turn ten: the same system prompt, plus nine questions, plus nine answers, plus the new one.

The window is just how much text fits in that box before the API says no. And everything in the box gets processed. Every time.

What attention actually does

Inside the model, attention has a job that's simple to say: every token looks at every other token and decides how much it cares about each one.

10 tokens → 100 pairs
1,000 tokens → 1,000,000 pairs
100,000 tokens → 10,000,000,000 pairs

Ten times the context isn't ten times the work. It's a hundred times the work. (That's just arithmetic: cost grows with the square of the input.)

Here are the three reasons big context hurts.

Reason 1 — attention is a budget

For every token, the attention weights add up to one. Always one — that's what softmax does.

So when you paste in fifty more documents, you don't hand the model more focus. You split the same focus into more pieces.

Reason 2 — lost in the middle

Researchers took one correct answer and moved it around inside a long prompt. Same prompt, same question, different position. Then they measured accuracy.

Near the beginning: good.
Near the end: good.
In the middle: much worse.

(Liu et al., Lost in the Middle.) So your most important paragraph, sitting at 60% of a long prompt, is in the worst possible spot in the whole file.

Reason 3 — distractors in your own data

This is the one I hit most in real code. The famous needle-in-a-haystack test is easy, because the needle looks nothing like the hay. Your production data is not like that.

Four things you can actually change

2. Use the edges. Instruction at the top. Data in the middle. Then repeat the actual question at the bottom, right before the model answers. That last line costs you nothing, and it works.

The takeaway

The context window is a hard limit on what fits. It was never a promise about what the model can use. Treat it like bandwidth you're paying for, and send the smallest thing that answers the question.

What's the biggest prompt you've ever shipped to production? And when you cut it down, did it get better or worse? Tell me below.