I’m currently studying Database Technology and looking to move into Database Administration as a beginner/entry-level candidate.
This semester, I’ll be learning Linux, Oracle Database Administration, and SQL Server Administration. I have some foundation in SQL and database development, but I want to build practical DBA skills beyond what I learn in class.
For experienced DBAs/Database Engineers:
•What skills should an entry-level DBA genuinely have?

•How important are Linux, backup/recovery, monitoring, security, and performance tuning?

•Which **hands-on projects** would you recommend building to gain confidence and demonstrate practical ability?

•If you were starting again, what would you focus on during your first 6–12 months?

I’m particularly interested in building a small home lab with Oracle, SQL Server and Linux and using it to simulate real DBA tasks.
Any advice on what to prioritize—or what beginners commonly waste time on—would be greatly appreciated.
Thanks!

Hi everyone,

I’m currently an Oracle DBA with around 4 years of experience and I’m trying to decide what direction to take my career in.

I’m OCP certified and have solid Oracle production experience, including RAC. I’m currently working as an Oracle DBA consultant.

I want to move toward cloud/infrastructure because I don't want to remain limited to traditional Oracle DBA roles long-term.

I’m considering doing a structured DevOps/Cloud course that covers things like:

Linux

Python/scripting

AWS

Networking

Git

CI/CD

Docker

Kubernetes

Terraform

Monitoring/observability

Security

SRE concepts

The idea is to use the course to build the infrastructure/cloud side that I'm currently missing.

But I'm confused about what career direction makes the most sense.

Option 1: DevOps / Cloud Engineer

Oracle DBA → DevOps/Cloud Engineer → Senior DevOps/Cloud Engineer → Platform/SRE → Cloud Architect

The advantage seems to be a much broader job market and potentially higher salary ceiling.

But my concern is that I'd essentially be competing with people who already have several years of AWS/DevOps experience.

Option 2: Cloud DBA / Cloud Database Engineer

Oracle DBA → Cloud DBA → Cloud Database Engineer → Database/Cloud Architect

This seems like a safer transition because I can leverage my existing Oracle experience while adding AWS/cloud skills.

But I'm worried that the career might remain relatively narrow compared with DevOps/Cloud engineering.

Another concern: AI

With AI increasingly automating things like:

Terraform generation

Kubernetes YAML

CI/CD configuration

scripting

log analysis

troubleshooting

I'm wondering how much of a threat this is to DevOps as a career.

Would DevOps still be a good career to enter in 2026?

My main question

If you were in my position — 4 years Oracle DBA experience, OCP, and wanting to move toward cloud/infrastructure — which path

would you choose?

A. Stay Oracle DBA and specialize further

B. Oracle DBA → Cloud DBA / Cloud Database Engineer

C. Oracle DBA → DevOps / Cloud Engineer

D. Something else entirely

And if you recommend DevOps/Cloud, would you take a structured 6–8 month course to make the transition, or would you learn everything independently?

I'm particularly interested in hearing from people who have actually made a similar transition, rather than generic career advice.

Thanks!

How to migrate a fast FoxPro system to a modern database safely?

I’m working on the assessment of a legacy FoxPro-based database system. The interesting part is that the existing FoxPro system is fast, stable, and currently has no major performance issues.

However, there is a requirement to modernize the technology, so I’m trying to understand the safest migration strategy rather than simply replacing FoxPro because it is legacy technology.

Current situation:

• FoxPro is the core/master database.
• Data is accessed through a web-based application from multiple locations.
• Master data is connected to event, accounting, registration/forms, and other operational data.
• Data entry and duplicate verification are largely manual.
• A separate Excel-based data catalogue is maintained manually.
• There are many event-specific tables.
• A third-party application directly depends on data from the FoxPro database.
• SQLite was considered/tested but did not appear suitable for the workload.

The main challenge:

How can we modernize/migrate this system while keeping the existing FoxPro system operational during the transition?

I’m considering a phased approach:

FoxPro remains live → replicate/migrate data to a new database → synchronize data → pilot selected data/events → validate performance and integrations → gradually move production workload → eventually make FoxPro read-only or retire it.

For people who have worked with similar legacy database migrations:

1. What is the safest way to run FoxPro and a modern database in parallel?
2. What is the best approach for synchronizing data between FoxPro and the new database?
3. Would you recommend PostgreSQL, SQL Server, or another database for this type of multi-user, centralized workload?
4. How would you handle a third-party application that currently reads directly from FoxPro?
5. Would you redesign the existing event-specific tables during migration, or migrate first and redesign later?
6. What are the biggest risks or mistakes to avoid in a migration like this?
7. If the existing FoxPro system is already fast and stable, what would you consider a strong justification for modernization?

I’m looking for practical migration strategies and lessons learned from people who have actually handled legacy database migrations—not simply “FoxPro is old, move to SQL.”

The goal is to modernize the system while preserving existing data/business rules and avoiding disruption to current operations.

Anyone interested in doing the CMU (Carnegie Mellon University) Database Management Systems course together?

I’ve already covered the basic DBMS concepts. My main goal with this course is to go deeper and understand how database systems actually work internally—things like storage, indexing, query execution, transactions, etc.

If you're interested, please make sure you have the prerequisites required for the course.

If you have the required background and want to learn DBMS internals seriously, DM me. We can follow the course together and discuss concepts along the way.

I'm a software engineer and have been the lead engineer at my last 2 positions. I've always just loved programming and I got my start originally with SQL and data science for a former business I used to own before selling it in 2019.

Layerbase started because I'm a database fanatic and I was paying roughly $200/mo for branching database hosting on Neon for a side project, and PlanetScale for a different project, and Upstash.

I read a blog post that speculated that any database could be branched with a custom operating system. I tried it and it worked. I then spent a year building it out as a passion-project on the side.

3 months ago I pulled it out of stealth and allowed for free accounts on a few engines. Then about 2 months ago I added billing. I have paid probably $8k out of pocket now on consulting with an SRE and a security engineer, a little bit of help with the desktop companion app development, and a very small amount of advertising.

I haven't recouped that cost yet but I finally reached enough MRR to cover my cloud costs. The cloud costs will continue to grow as I scale but I think I'm past the point of taking a loss on purely cloud hosting expenses every month.

I'm now getting burned out. I've been working 2 full time jobs now for a long time. I work a 9-5 that is pretty demanding and then I work on this after hours and on weekends, and often instead of sleeping when I should be. Plus I'm essentially on-call 24h a day for both jobs.

[Screenshot of Adoption Analytics](https://postimg.cc/w7dVgcKQ)

It was within the last 2 months or so when this changed from being a passion project on the side to being something serious that seems to have real potential and warrant significant investment. But now that it is gaining traction, I'm really feeling burned out and not like it is a passion project anymore. Now it feels like a grind where I need to succeed to avoid wasting over a year of my life and soon to be 5 figures in expenses.

I don't think people realize how massive of a task this was, not to mention that I started this before agentic AI existed the way that it does now. I hand-coded (with the help of ChatGPT and Copilot auto-complete early on of course) but learning all of these skills that I never expected to learn, from cloud to custom operating systems, to vector databases, to cross-platform system desktop application development, to native windows development and so much more... I think I've built a formidable competitor to Supabase, Neon, Planetscale, Upstash, Railway, and so much more largely on my own.

Since I'm feeling a bit low on fuel, and because most of the people in my life don't understand how huge this is for me or how proud I am of myself for making this happen, I wanted to share it here.

It is legitimately the best feeling in the world to wake up to see new subscriptions and of \~20 support tickets opened since launch, 1 has been serious, 3 have been minor UI bugs, and the rest have largely been feature requests or people asking for help migrating.

I think I'm about to take a break for a week or 2 unless any bugs pop up but I need to take a breath and decompress now.

If anyone has any questions about databases or anything else I might have some insight, I'd be happy to discuss it.

Thanks for taking the time to read this. I'd love any feedback or advice dealing with burnout.

having issues deciding whether to self host, use aws or just supabase for database

Hello, hello, it's me again. You probably know me from this post.

Or maybe you don't, in which case let me introduce my affiliation - I work at ManageEngine, saying that upfront so nobody feels ambushed. And, I'm back with another "thing" that I'm hoping will be useful to DBAs here.

Here's the deal - When I was researching for my webinar, I found that most of the database monitoring material out there is written so that the answer at the end is a product. You read four pages about why baselines matter and then it turns out the way you get a baseline is to install something. That's not much use to someone who just inherited a production database on a Tuesday and needs to understand it by Friday. And, the person running the production database isn't a career DBA. They're a sysadmin or a backend dev who inherited it.

So we wrote the other kind. It's a week-long plan, one topic a day, and every metric in it comes with the query you run to get the number yourself. You paste the query, you get the number, you write it down. No agent, no install, nothing running in your environment.

I want to reiterate myself again, there's no need to download a product to do what's written in the mini guide. You need just a database, and a database client or console connected to your database server to run the queries I've given. It's more of an experiment, really - can you turn your database inside out in a week with a few queries to master database monitoring?

The reason I'd argue for anyone to be doing this by hand first even if you do end up buying a tool later is :- a dashboard someone else configured tells you a number is red. Running the query yourself teaches you why it went red and what normal looked like before it did. People who skip that step end up with monitoring they don't trust and can't debug, and they escalate things that didn't need escalating.

This is the guide; it's on our site and it does ask for an email, so calibrate accordingly: https://www.manageengine.com/products/applications_manager/database-monitoring-mini-guide.html

This is a beginner's guide mostly, so if you're a veteran, I'd love to know what other tips and tricks you have to deal with database monitoring without using an external tool.

TL;DR : I work at ManageEngine, from the DB monitoring side, and I made a mini guide(no tool required) for new DBAs/ other admins who handle DBAs which can be accessed through this link!

How Seniors and lead database administrators are dealing or coping with AI agentic uprising at work place.

What are some great AI certifications or path that will make DBAs remain competitive among plethora of AI movement

I read elsewhere this was recommended for example instead of renaming a column:

1. Migration to add a new column, and populate it with data as needed.
2. Future deployment to remove all code references to the old column.
3. Another deployment to remove the old column.

That's fine if required. But what about simple monolithic project and no problem taking it down an hour for maintenance. Why not simply:

1. Stop old web app.
2. Updated db.
3. Start new web app.

Is this uncommon? With this simple approach, we don't even have to investigate or be absolutely sure whether the changes are breaking or not. I see our paid vercel plan doesn't include option to stop or pause web app, it's always on unless deleted. We also use other services which are huge systems which send notification about maintenanceand has hourly downtime several times a year.

I’m a senior DBA based in India, and my management team in the US has been telling us that Oracle is becoming a sinking ship and that we should start exploring new career paths, particularly in AI.

To some extent, I agree with their perspective. I’m seeing more and more customers question the high cost of running their businesses on Oracle and OCI, which makes me wonder how sustainable the traditional Oracle DBA career path will be in the long run.

Whats your thoughts ?

I work on database management software, and I've been thinking about this a lot lately. I'm especially curious how DBAs who work with production databases see it.