
Stripe complete schema for database/API design learning and inspiration - fgribreau
https://github.com/FGRibreau/stripe-schema
======
davismwfl
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

------
jbverschoor
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.

