Hacker News new | ask | show | jobs
by DevKoala 1522 days ago
If the database is a shared resource across multiple teams, it makes sense that there is specific ownership of it. It could be devops, but someone needs to be looking at the larger picture. Development teams/individuals tend to be myopic when it comes to the consumption of shared resources; “my app”, “my feature”, etc.

Also, I’ve worked with some excellent DBA’s that taught me a thing or two about PG query optimization, and scaling a cluster to the needs of the business. While I’ve also dealt with some awful ones that only stood in the way of projects by creating incredibly contrived security roles. Make sure this individual is a true expert whose skills add value far surpassing that of the managed cloud services.

1 comments

Thanks for the reply!

For the folks you worked with in the past that were excellent, were they full time DBAs in terms of their title? Or were they folks that were in other departments (i.e. devops) that also had expertise in good DB design in scaling?

It might also depend on the size of the company the particular need? Evolving a monolith-like DB already in production to a better structured state might be much to ask of an individual.

I just checked the LinkedIn of the individual whom I consider excellent, and his title is actually Database Architect. I feel that is fair considering his skills and the projects I know he handled.

Everybody in that engineering org worked with big data and could design the data store system for a regular startup easily. However, this individual’s role was to optimize our multi tenant PG cluster design to build some complex CDP functionality on top of it.

I now work for a larger organization and when I run into the individuals that own shared database resources all they do is impose contrived read/write permissions. However it makes some sense since I work with PII in some cases.

Got it, yea seems this is more valuable in a big data context or when actively pressed up against scale limitations of a DB deployment. Funny on the the last piece as well - appreciate the thoughts here!