I don't know who this guy is (maybe I am out of touch), but it doesn't appear he works at stripe or is affiliated from what I see, maybe I just missed it. So is this actually Stripe's schema or just what he thinks it looks like or should look like?

Either way, it is always interesting to see how other people lay out data systems, especially when the data system is for a large dataset.

A couple of key things stood out to me right away though. Using varchar for every id, I get in very high transaction tables int (even bigint) can sometimes be a problem but there are solutions to those and int performance will always be superior, not to mention far less memory/disk space used generally.

Also the use of bigint for fixed range values is a little weird, like the legal_entity_dob_day, month & year, where for each of them it could've been a 2 byte int and been fine (or even tinyint at 1 byte), taking up far less space. This isn't a big deal for a table with 1,000 records, but for millions/billions it adds up quickly. Probably on the accounts table the size difference is reasonably minimal, but the same thing is on transactional tables which will grow significantly so those extra bytes do matter. I have seen people standardize values this way for coding purposes but that generally isn't good DB architecture/design overall IMO.

Obviously stripe is super successful and if this is their actual schema, even if it was at one point, it worked for them. But if so I'd be interested in understanding their choices around like the varchar id's and bigint's for small fixed range values etc.

*edit -- clarified a little

I think this is deduced from the stripe api, which most likely resembles the actual implementation quite well. The ids could be some unique reference instead, and I’d assume that the metadata info are json fields in each table.

Nice to have it laid out. A relational diagram would be a great addition.