Hacker News Reader

Comment by conqrr | Hacker News Reader

Very nice article and looks like a great way to get hands dirty for anyone wanting to think like a DB engineer. Related question, for all the Database engineers out there. I have always had a keen interest to work on Databases. Having worked at one of the cloud providers and burn my high amount of ops and oncall, I am of the opinion most of the Database engineers usually have a bad wlb. Given the depth and complexity of all Database internals, Any major impact would take a few quarters to roll out, and its not a job for everyone. Is this mostly true?

View on HN

I worked at a DB product startup, doing DB internals development [storage engine, etc], for a few months (before my personal/family situation forced me to have to move on), and WLB seemed pretty reasonable -- though there was a mandatory on-call rotation, that's kind of expected at most startups in the cloud space.

People were very smart and friendly, and took vacations and all that kind of stuff. I'd say the "worst" part of working there was the amplification of my impostor syndrome?

I don't know if that's typical for the industry as a whole. I'd definitely like to get back into DB internals dev at some point, it's one of the few places in our industry where you get to do fundamental systems dev. The job I had was in many ways my "dream job" but family situation at the time meant I couldn't manage it.

I had the most fun of my entire career writing a DB from scratch at my previous job. It was fun while it lasted (i.e., until the money ran out)...

I have worked on internals of databases for a few years. WLB is just fine, we have oncall rotations same as everyone else. They are deep and complex systems, but mostly what that means is just that average tenure is very high as it takes forever to get up to speed and people generally don't get bored and leave, unless you give them good reasons to.

Overall I enjoy it a lot and would generally recommend it as a good field to get into if you want to tackle hard problems.

Edit: people seem to be conflating DBAs with engineers working on database internals. Those are very different jobs and I'm only talking about the second one.

I'm the de facto DB guy at work, WLB is fine... it's very rare that I have to work after-hours. The main reason for this is that our DBs are basically exclusively used during business hours, and if you set things up right it's rare that you'll get anything breaking on its own after-hours.

Also - maybe this is specific to me, but most emergencies I deal with are of my own creation. It's rare to have a DB spontaniously corrupt a page. Most emergency issues I deal with are performance-related (this used to take 2s, now it's taking 200s) and you can mitigate those ahead of time if you're thoughtful (breaking code up so you lean less on the query optimizer, automatic index maintenance, consistent and well-indexed join paths).

Depends what you mean on major impacts. A potentially breaking upgrade is a total nightmare, and never a fun process. But most (almost all?) of the things you do are much lower stakes, and definitely do not take a few quarters.

I read the commenter as referring to working on DB internals -- that is, building a database -- rather than working supporting workflows/queries on an existing DB product. But maybe I read wrong.

I think it depends on the environment. Yes, most production and even some test databases are critical to businesses. Any downtime or severe performance issues cause a lot of finger-pointing.

Where I work, most database patches are applied to test environments and let soak for a couple of months before rolling out to production.

And yes, I work a lot on weekends. My only complaint about my career as a DBA is that most of our work is behind the scenes and goes unnoticed until something breaks.

I can't judge your personal position/responsibilities but normally I think of DBA and database developer as not being the same thing (except for at small database startups where there's more overlap). At medium+ -sized database companies I've talked to the database developers are on call but likely don't have access to production. They are on call for bug reports from production users. Whereas DBAs are folks directly responsible for the database in production.

Reply on news.ycombinator.com