Probably a bit late, but... At traditional big companies, there are two main categories of DBAs, and data scientists would generally be separate. - Systems DBAs are responsible for making sure the database systems keep running. Scaling, high-level performance, updates, deploying new hardware for databases, setting up new databases and performance monitoring for them, investigating what's going on when databases slow to a crawl, that sort of thing. When I read "Oracle DBA", and particular "Oracle database admin", that's what I think of as most likely. - Application DBAs are more focused on writing database-level code for software applications (what the "programmers" or "software developers" write). Often, regular developers aren't experts in database queries - they can write them, but maybe not very complex ones, or maybe the ones the regular developers write are very slow. Application DBAs specialize in writing these queries and making them run quickly and efficiently. It could be that the position you mention is for this as well, and they mention Oracle because that's their exclusive database, and while most application DBAs can switch between variants of SQL, each vendor, including Oracle, has their own extensions. There often is at least some overlap, more so at smaller shops, but those are the broad swathes of responsibility. Sometimes the difference is called out in the job description, but just as often it isn't. And it's worth mentioning two more related specialties, including your chosen field: - Data architects are responsible for building the structure of the database in a way that is high-performing for the company's tasks (versus using existing tables efficiently, as application DBAs do). For small applications, you can have any old developer design the tables, but for very large companies with lots of data, designing them in a way that scales to the data becomes a considerable challenge. - Data scientists are responsible for finding patterns and uses for large amounts of data. Nowadays the problem isn't collecting lots of information; it's finding out how all that information is useful. Data scientists make those connections, and while database skills will be useful in that, making useful insights and connections is a very different focus than the performance-focused, problem-is-already-defined role of the application DBA. It's more exploratory. I suspect that most data scientists would not find DBA positions to be fulfilling. There usually isn't much creative freedom in DBA roles (even less if it's a systems DBA role), they're very technical, and as mentioned the focuses differ. It's certainly possible to become a master of DBA, and if you're the type of person who enjoys perfecting that data-performance-related craft, or being the guy everyone can count on to fix things when the data center goes down, it might be for you. But it doesn't have the creativity that you likely are expecting given your course of study, and is usually an underappreciated (and in other companies, underutilized) role. It seems a little strange that a company would try to hire a data scientist for a DBA role. It could indicate several things, including not really knowing the difference themselves; needing a DBA, and having plans that involve some data science but not the money to hire both a DBA and a data scientist, and thus being happy to see a data scientist apply; or actually wanting a data scientist but not wanting to pay the (generally, though not always) higher data scientist salary, and thus hoping they could lure one in with a DBA role. The former would be concerning, especially if the tasks they describe are DBA tasks; the middle would likely leave you mostly bored, though it could help sharpen your database skills a bit if needed and it's an application DBA position; the latter might not be bad as a way to get a couple years of experience, before moving on to something that pays better or is at a company with more data scientists. And there is something to be said early in your career for a position where the pay isn't the greatest, but you can learn, have some autonomy if it's a smaller company, and earn some good recommendations. Just don't stay forever if you do well and hit the ceiling there. Source: I'm a "regular software developer" who has worked at mid-size and large companies over the past 7 years, and my father was in IT for almost four decades, including a decade as one of the top data architects at a large corporation (which overlapped with the time when data science became its own distinct field; he knows several people who transferred from DBA or data architect roles into data scientist roles, when the field was new enough that you could do that fairly easily).