upvote
SRE here who has dealt with this before.

Everything in article is excellent point but other big point is schema changes become extremely difficult because you have unknown applications possibly relying on that schema.

It's also at certain point, the database becomes absolutely massive and you will need teams of DBAs care and feeding it.

reply
This is true. But at the same time people need to understand that most companies will never hit that certain point. It's a matter of if, not when.

Everyone tries to plan for a world where they've become one of the hyperscalers. Better to optimize for the much more likely scenarios.

reply
We were not a hyperscaler, we were boring company that you never heard of.

Database is still 40TB with 3200 stored procedures.

reply
I've dealt with postgres DBs larger than that in size though with no stored procedures and have never run into such problems. Except for a single table in a single DB at one stop, and that was a special case of people being extra stupid.

Granted, DB size isn't the best metric to be using here in terms of performance, but it's the one you used.

reply
Not only will you need a team of DBAs caring for it, but you'll never be able to hire them.
reply
No organization I have seen prioritizes a DBA's requirements, concerns, or approach. They certainly don't pay them enough to deal with that bullshit, so I was out.
reply
The things that impact the most are locking/blocking, data duplication (ghosting due to race conditions), and poor performance. The best advice is RTFM the documentation for your database; yes, it is a lot to digest that is why DBAs exist. Most of these foot guns are due to poor architecture. You have to imagine multiple users/processes are literally trying to write to the same record at the same time; when you realize this, a single table with simple key-values is completely inadequate.
reply
Pro: every team probably needs user information, so don’t duplicate it in weird ways with uncertain consistency.

Con: it’s sadly likely that no one on your staff knows a damn thing about how an RDBMS works, and is seemingly incapable of reading documentation, so you’re gonna run into footguns faster. To be fair, this will also happen with isolated DBs, and will then be much more effort to rein in.

reply
They are very similar to the pros and cons of having a monorepo. It encourages information sharing and cross-linkage between related teams. This is simultaneously its biggest pro and its biggest con.
reply