At one bank, the Python source code lives in the database, not on disk

A Python where the code itself lives in the database

Most programmers have never seen it, because you only see it if you work inside an investment bank. Cal Paterson's oral history of "Bank Python" describes proprietary forks of the whole Python ecosystem, built in-house and walled off from the outside world. He anonymises one such system under the name Minerva and walks through its parts.

The centre of gravity is Barbara, a global hierarchical key-value object store built on nothing more exotic than pickle and zlib. Applications don't talk to Postgres or stand up microservices; they write Python dataclasses straight in and read them straight back. As Paterson puts it, "the default ring is more or less a single, global, object database for the entire bank." Data lives behind tidy paths like /Instruments, /FX, and /Equities/XLON/VODA/, with a soft limit of roughly 16MB per compressed object to keep people honest. Rings are namespaces; "overlays" let you stack one ring's view on top of another.

Then comes the line the thread kept circling back to:

"Time to drop a bit of a bombshell: the source code is in Barbara too, not on disk. It's kept in a special Barbara ring called sourcecode."

No files. No git. The code that runs the bank is just more objects in the same database it operates on, which is why Minerva needs its own mandatory IDE and its own job runner to function at all.

The rest of the stack rhymes with that choice. Dagger holds every financial instrument in a directed acyclic graph and automatically reprices derivatives when an underlying moves, giving you spreadsheet-style modelling in Python with version control on top. Instruments combine into positions, positions into books, books nest all the way up to the whole bank. Walpole is a bankwide job runner, Jenkins and systemd fused, where deploying a service means writing an ini file instead of fighting Kubernetes. MnTable is a memory-dense table library tuned for gigabyte-scale data with b-tree indices, where pandas would tap out.

Paterson's thesis is deliberately heretical: "one big something rather than many small somethings." One codebase, one database, one job runner, and the accidental complexity of the modern microservices stack mostly evaporates. Financiers who will never be great engineers can still write useful Python and ship it. The price is steep too, and he names it: skills atrophy in the monoculture, new starters take months or quit "in a fit of pique," and the whole edifice can never leave the building.

The thread fills in who built it, and when

The discussion is small but stocked with people who have clearly lived inside these systems. The most useful contribution is a genealogy. A commenter who worked alongside the original system traces the whole pattern to one place:

"much of this originated with SecDB/Slang at Goldman — SecDB … being the object store and slang the somewhat quirky C like language … Some of the folk that built that … ended up at JPM and Merrill where they built the Python centric version - Alpha and Quartz respectively." — a commenter who used Slang professionally

So Barbara has a real lineage: Goldman's SecDB and its Slang language in the 1990s, reborn in Python as JP Morgan's Athena/Alpha and Bank of America Merrill's Quartz. The same person notes Slang let you put spaces inside variable names, the kind of detail you only know from typing it.

A second voice put a name to what it feels like from the inside:

"these things tend to have fuckin terrible documentation. Good luck figuring any of this out. And you can't google it and your AI is just as lost as you" — an engineer who worked inside a large financial org

That is the hidden cost of a private fork of an entire ecosystem: every Stack Overflow answer, every model weight trained on public code, is suddenly useless. He compares the people who spend whole careers in there to SAP consultants: a skillset welded to a single employer.

Not everyone reads the architecture as exotic. One reply waved at a much older relative:

"Weirdly not dissimilar from MUMPS systems." — a reader who recognised an older pattern

MUMPS, the 1960s language whose global persistent arrays still run hospital and banking back-ends, did the code-and-data-in-one-store trick decades before anyone forked Python. Another regular pushed back on the instinct to sneer at the in-house wheel-reinvention:

"why didn't they just use … The answer is often that the battle-hardened mature off-the-shelf solution did not exist at the time the code was written. You're doing software archaeology." — a reader answering the "why not buy it" instinct

The regret in the thread is that none of it will ever ship. Financial models are secret sauce; this plumbing is not, and yet it stays locked in the vault.

"I think it is a pity they'll likely never open source any of this stuff … this kind of underlying infrastructure isn't really 'secret sauce'." — a commenter who distinguishes models from infrastructure

Which is the quiet point under the whole piece. Banks have spent thirty years independently inventing the same global-object-database-plus-DAG pattern, refining it against real money, and the rest of the industry will never see a line of it, left to re-derive the same ideas, badly, in public.