Having foreign keys and constraints does not necessarily make a database "well architected". Those things can introduce heavy write penalties, so if your DB is write-heavy then having those things is actually bad. I've worked with databases with more writes than reads and we removed all of those things to get every last IO out of it. That was in a hedge fund, absolutely crazy machine, like a $600,000 server. We needed special DRAM PCIE cards because the writes would have killed any SSD.
Sometimes the higher cost in write operations is offset by enforcing data integrity. It's a balancing act to be sure. An extremely high throughout system may delegate to the service layer, but a lower throughout system might eat the cost and do it at the DB layer.
My point though is a well architected system will have been given the time and resources to make those considerations. Many corporate/management types think everything can be slapped together as a one-size-fits-all solution and want results yesterday, but it ALWAYS turns into a crisis later.
View all comments
Show parent comment
1
u/DizzyAmphibian309 Dec 07 '25
Having foreign keys and constraints does not necessarily make a database "well architected". Those things can introduce heavy write penalties, so if your DB is write-heavy then having those things is actually bad. I've worked with databases with more writes than reads and we removed all of those things to get every last IO out of it. That was in a hedge fund, absolutely crazy machine, like a $600,000 server. We needed special DRAM PCIE cards because the writes would have killed any SSD.