It's also a very slick integrated development environment for financial use cases. The securities/price data are exposed as first-class entities in an ORM laye

It's also a very slick integrated development environment for financial use cases. The securities/price data are exposed as first-class entities in an ORM layer and you can manipulate them easily with scoping rules. For example, if you want to get the current USD/JPY rate, it's just: Rate(Security("USD/JPY")) If you want to know what the price of an FX contract is under different rate regimes, you can actually set that price and then reevaluate the contract, e.g. SetDiddlescope() { Foreach(X, [90, 100, 110]) { Rate(Security("JPY/USD")) = X // Only takes effect within this scope Print(X + ": " + Price(MyFXSwap)) } } How this actually works is that most object's fields are dynamically recalculated using an early form of functional reactive programming (note that SecDB was mostly built in the 90s). Fields specify their dependencies, and when their dependencies change, the field's value gets invalidated. This is very similar to how ReactJS or Angular work. Unlike React or Angular though, you can force intermediate calculations to take on certain values as well; for example, in the scope above, you can also force Price(MyFXSwap) to take on a particular value. This is useful, for example, you had a book of securities, MyFXSwap was one of them, and you wanted to see how the price of your book would change. Even though all the securities are actually in a database somewhere, anything happening locally gets cached to an in-memory database so the performance is pretty decent. The security database itself, btw, was much closer to a pure distributed object store; there wasn't much in the way of querying ability.