So what I imagine when we talk about a single database is just some mapping of stock shares to owner. So to keep track of who owns what share, when some shares gets transferred you just update each row accordingly. (Imagine a stock with 10 total shares and X sells to Y shares #1, #2, #3, you'd just update the table and set owner=Y where share id is in (1, 2, 3))

But for such important financial data you don't want to just update your table and throw away your history. You'd like to also keep a record of what changes occurred. Maybe you'd like to audit your database, and find out the path of ownership from which a current owner obtained their shares. Maybe you'd like to make your history immutable, so as to not have headaches later on trying to validate the current state, or to discourage tampering with the database.

So now you have a datastore where the current state relies on an ever-growing stack of immutable changesets. This sounds exactly like what we talk about when we talk about blockchains. There are people who define a blockchain more strictly (e.g, The Blockchain(TM) with decentralization and crypto), but I think the author was going for the former meaning.

That is to say, you can implement a blockchain and still be using a single well-designed and well thought-out database.