You misunderstand. It's a database built purposely for ensuring transactions happen in an ordered manner an as correct of a way as possible. The constraints an

You misunderstand. It's a database built purposely for ensuring transactions happen in an ordered manner an as correct of a way as possible. The constraints and basic rules of accounting are generally pretty slowly changing so it makes sense in a domain that has: * Very slowly changing validity requirements. Things like (optionally) preventing overspending are things that are pretty intrinsic requirements of the domain (depending on the context, obviously many banks allow overdrafts so they can charge you a fee for spotting you the difference). The validation space is relatively small such that you'll want to allow most transactions that aren't blatantly wrong * Emphasizes correctness and ordering over everything else * The transaction rate is relatively inelastic, that is there aren't huge swings on how many transactions are requests per second such that dynamic scaling is not a desirable property to have if it means being less reliable/correct. Conversely, it's a known slow operation that most people are fine with not being instant. Ex. I'd much prefer my rent payment take 10s to process and be more or less guaranteed to be correct than it take 1s and not. That's why it's domain-specific. You can optimize for the things you care about in your domain most while reducing operational complexity to the minimum viable to meet those demands. It's amazingly well-focused and solves what I assume are hard, limiting problems that the existing financial infrastructure is not equipped to support.