When is it worth getting a DBA?

Question

I've now worked at a few tech companies ranging from 10 people to ~150 and I've never encountered a real DBA. How big does a company need to get before it merits getting a DBA? What are the criteria that need to be met?

Answer 1

Once database become a real bottleneck.

Answer 2

I would say in a company where collecting and mining data is the core business.

Answer 3

The need for a DBA is pretty subjective.

As long as you have databases, you will have to some maintenance that goes along with it, although SQL Server behaves well in most cases.

The requirement for a DBA depends on the size of the data IO more than the size of the workforce.

You will always have administrative tasks for this database that somebody has to do, effectively adding the DBA feather in their cap.

Answer 4

There are no strict rules, but some indicators you need DBA may be:

1. High level of company formality – if you have ISO or CMMI introduced, you will have some strict procedures about deploying software. DB deployment will be done by DBA.

2. Lot of servers – if your company has lot of servers, DBA will be needed simply to maintain then, tune them or patch them. Just to look after them.

3. Difficult applications – if your company has difficult to maintain applications, you will need to hire a few maintenance guys, one of whom will be probably DBA.

4. High availability applications – will probably need some DBA just to be on site. Just in case.

5. Developers not familiar with DB details – if your developers know only how to code, and how to design table, you will need DBA to handle all other DB related stuff.

Answer 5

A couple of things you can take into consideration when deciding.

Man power:

1. Do your developers know the database platform used by applications intricately?
2. Are they able to perform the general function that a DBA does (administrative tasks)?
3. Can your developer handle the administrative tasks in addition to their current work load?

If yes, let the developers handle it. Hides

Server Work-load:

1. Do you have 30 different databases across 20 different servers that replicate to 50 other servers?

Get a DBA!

Answer 6

Most software engineers know at least basic database maintenance. It becomes valuable to hire an employee dedicated to database administration when databases become an issue and you (or employee(s) who you trust to maintain the database) can no longer find the time to do it yourself (themselves).

Answer 7

We have DBAs mostly for separation of duties concerns. Developers can't run any scripts on the production databases. Our developers never have write access to the databases they support, unless it's granted to them for normal usage of the application. So, if you're worried about control, a DBA might help.

Answer 8

Wherever data is a major part of a company's business (bank, insurance companies, airlines, etc) there will be many dba's.

Probably most software houses don't need a dba.

Answer 9

The company where I work interprets the Sarbanes-Oxley Act as forbidding a developer from having administration access to any production machine. (I say 'interprets' because I've never read the legislation.) If that's correct and you work for or are acquired by a Fortune 500 company (where I am told S-OA applies), nobody who codes may be an administrator.

At that point, you either have to get a DBA or hope that you have someone in networking who knows what a table is.

Answer 10

Agree with Smok1's answer, just wanted to add a few points.

Check the size of your log file, if it is much larger than the database, you probably need a dba because clearly your backup policy is not working correctly.

Also if your queries frequently time out, you have developers who often write cursors, or users complain about how slow your application is, you probably need a dba to performance tune.

In general if you are designing a complex data-driven application, you should have a dba and/or database developer specialist on your team. Databases are the heart of the most business applications and should be designed by specialists who understand relational design, set-based queires and performance tuning not application programmers who generally make poor database design choices especially when they try to make relational databases fit an object oriented model rather than the relational model that they are optimized for.

The time to hire the dba or data analyst is when you start designing, not after you have ten million records and every query times out. A large portion of performance problems are a result of a poorly designed structure and this is much harder and more costly to fix after you have reached the point where everyone knows how slow it is.

Answer 11

Once you have a database that contains important information, and you don't have that perfect developer that can 'do it all'. Most developers know some pl/sql, they know how to create tables and do a lot of things, but from my experience "most" developers no little about actually managing a database server. Sure, they can start the services, create tables, maybe even play with the namespace, but how many developers really know what they are doing?