My first real job was a DBA at Microsoft, on a very large marketing database (aprox 1.5TB in 2000)
That experience, how much work is required for "real" production databases, led a bad taste in my mouth. I stay away from self-hosted db's to this day. (example, I use google cloud datastore nowadays)
IMHO that's still a very large database today. Most people don't appreciate that restoring that is likely going to be 4-8 hours given SAN and network speeds unless you're in a super modern SSD-driven environment.
When it goes higher, 5TB, 10TB, 15TB, that's out of my league, and I just say days of downtime. Also remembering those are often spread across two servers like in an Availability Group, which means two restores...
I know people will pipe in and talk about partitioning and read-only file groups and partial restores. Except that in the real world I've seen zero of it, and it's not general DBA knowledge, it's likely the top 1% or even 0.1%.
And even then you'll still have massive downtime (depending on how the application is architected to support this), and you'd better have bullet-proof testing (and 20TB spare disk space to repeatedly test it with), to make sure a complex restore like that is easy to carry out while under the pump of an outage.
That experience, how much work is required for "real" production databases, led a bad taste in my mouth. I stay away from self-hosted db's to this day. (example, I use google cloud datastore nowadays)