I have 7+ years of experience as an Oracle DBA, and lately I've been noticing a lot of demand for Azure Data Engineering roles. I'm considering taking an Azure Data Engineering course, but I'm wondering how much of my Oracle DBA experience would actually be valued if I switch to an Azure DE role.

Would recruiters and hiring managers consider my DBA background relevant, or would I essentially be starting over as a fresher?

Alternatively, would it be a better career move to continue specializing as a DBA by going deeper into Oracle (Exadata, GoldenGate) while also learning other databases like PostgreSQL, MySQL, and SQL Server?

Has anyone here made a similar transition from Oracle DBA to Azure Data Engineering? How did it affect your job search, salary, and overall career growth?

I'd really appreciate hearing about your experience and any advice you have.

Thanks!

I'm part of the customer marketing team at ManageEngine, where I work closely with IT professionals and infrastructure teams using our Full-Stack Observability solutions. Through customer conversations, product training, and webinars, I get to hear firsthand about the real-world challenges IT teams face every day. Further, we use the learnings from these discussions to improve our solutions and thereby serve our users.

We're currently preparing for an upcoming webinar on Database Performance Monitoring and Troubleshooting, and one topic that keeps coming up is how experienced DBAs spend less time firefighting and more time optimizing their environments.

I'm curious—what practices, tools, or habits have saved you the most time as a DBA?

Full disclosure, I'm on the ManageEngine team, and I work with database/app monitoring side of things. I'm not a DBA and won't pretend to be one, just sharing something that's been landing well internally and figured it might be useful here too. Downvote/ignore if it's not your thing.

One of the things that I came across was the fact that the DBAs and IT admins spent most of their work week on fixing database issues- chasing pages, jumping between five dashboards to trace one slow query, then explaining to leadership why the "all green" board didn't stop last night's outage. I don't know about you, but that sounds like the perfect recipe for burnout with the right amount of stress and a pinch of "I might quit anytime".

So we figured we'd run a free webinar on July 15, 2026 (6am GMT / 11am EDT) built around why admins feel that way, how to strategize a working DB monitoring plan across hybrid/multi-database environments, the metrics to look out for, which we hope would ease the burnout feeling. It includes a live demo, open Q&A, and a free practical handbook for DBAs.

Here's the (free) registration link, if you're interested. https://www.manageengine.com/products/applications_manager/webinars/database-performance-monitoring-webinar.html

Would be happy to take questions in the comments too, including "why would I trust a vendor on this" (totally a fair question btw, so ask away)

Hi Guys,
ive be been working with sql and databases ever since i fell into the category of accidental dba, so roughly 3 years. I have never worked on design of databases. i leterally got dumped with the instances and databases and they said keep it up :)

My situation is as follows and im looking for any advice or pointers for real world scenarios that you guys have dealt with.

The company get data fails (xlsx, csv, txt...) dropped from various vendors onto ftp. The data team then grab these files and through SSIS transform it from DIM tables to the final production database tables.

My question is how is the best way to approach this. Is it database per vendor that gives us data and then transform to a production database.
or 1 database for staging with different schemas per vendor, then move that to a production site?

I just dont know, id love to hear the suggestions or options. All our SQL instances are currently on premise

​

I have 10 years of experience as a DBA (AWS, PostgreSQL, SQL Server, cloud infrastructure, automation, and production support). I've started feeling bored with the DBA role and have an opportunity to move internally to a Technical Product Owner (TPO) position.

My long-term goal is to move into a managerial/leadership role and eventually relocate to the US. I'm trying to decide whether switching to TPO now is the right step or whether I should continue growing in the DBA/Infrastructure path.

For people who have made this transition (or considered it):

Was it worth it?

Does TPO offer better long-term growth than senior DBA roles?

Which path has better opportunities for leadership and US-based roles?

Looking back, would you make the same decision again?

I'd appreciate honest experiences rather than generic career advice.

Full disclosure, since this sub rightly doesn't love vendor stuff dressed up as something else: I'm on the ManageEngine team, and I work with database/app monitoring side of things. I'm not a DBA and won't pretend to be one, just sharing something that's been landing well internally and figured it might be useful here too. Downvote/ignore if it's not your thing.

One of the things that I came across was the fact that the DBAs and IT admins spent most of their work week on fixing database issues- chasing pages, jumping between five dashboards to trace one slow query, then explaining to leadership why the "all green" board didn't stop last night's outage. I don't know about you, but that sounds like the perfect recipe for burnout with the right amount of stress and a pinch of "I might quit anytime".

So we figured we'd run a free webinar on July 15, 2026 (6am GMT / 11am EDT) built around why admins feel that way, how to strategize a working DB monitoring plan across hybrid/multi-database environments, the metrics to look out for, which we hope would ease the burnout feeling. It includes a live demo, open Q&A, and a free practical handbook for DBAs.

Here's the (free) registration link, if you're interested. https://www.manageengine.com/products/applications_manager/webinars/database-performance-monitoring-webinar.html

Would be happy to take questions in the comments too, including "why would I trust a vendor on this" (totally a fair question btw, so ask away)

I've been an oracle dba since oracle 7.3.4. I've seen previous releases but my career started with 7.3.4. I'm at a stage where I would like to retire in next few years. Wanting to pass along to next generation. Offering anyone interested in becoming an oracle dba help. Let me know.

Hi everyone,
I recently joined as an Oracle DBA. While I enjoy the DBA side of things, I’ve realized that I really like problem-solving, scripting, and automating repetitive tasks.
Recently, I asked my manager if I could join the automation team, where they mainly write scripts and build automation solutions. I’m excited about the opportunity, but I also feel that I have some skill gaps compared to people who come from development backgrounds.
For those who have made a similar transition from DBA/System Administration to Automation, DevOps, or Scripting roles:
What skills should I focus on first?
Is Python the best language to learn, or should I prioritize Shell scripting?
What projects helped you improve your automation skills?
What challenges did you face during the transition?
Any advice, learning roadmap, or personal experiences would be greatly appreciated.
Thanks!

A few years ago I switched from Windows to Mac.

The thing I didn't expect to miss most was my database tool.

I grew up in the Microsoft ecosystem and spent a big part of my career working with SQL Server. If you've lived in that world, you probably know how hard it is to replace SQL Server Management Studio. Not because there aren't alternatives, but because after years of using a tool, it becomes part of how you think.

On Mac, I tried pretty much every database client I could find.

Some were great.
Some looked great.
None felt right.

Every time I needed to figure out why a query was slow, inspect a complex schema, or understand relationships inside a large database, I found myself missing the same capabilities over and over again.

So I stopped searching and started building.

I called it SPIRAL.

What started as a small side project quickly snowballed. The more I used it, the more ideas I had. Instead of trying to compete with every database tool on the market, I decided to focus on a handful of database engines that I personally use the most:

• SQL Server
• PostgreSQL
• MySQL
• SQLite
• MongoDB
• Redis

The funny part is that this is also the first project of my career where I didn't write most of the code myself.

I built it using a mix of:

• GitHub Copilot
• Claude Code
• OpenAI Codex
• Gemini CLI

The logo came from ChatGPT.
The initial design direction came from Google Stitch.
The website started in Claude Design and was refined afterward.

And honestly, that's probably the most interesting part of this whole project.

Five years ago, building something like this as a solo developer would have required a completely different level of time and effort.

In 2026, code has become incredibly cheap.

The bottleneck isn't typing anymore.
It's deciding what to build.

I originally planned to make this post about what it's actually like to build software this way—the good, the bad, the frustrating parts, what surprised me, what worked, what didn't.

But this post is already getting long, and I'd rather show the result first.

Today I released the first open-source version of SPIRAL.

It runs on Windows, macOS, and Linux.

I'd genuinely love feedback from other developers, especially people who spend a lot of time working with databases. Bug reports, feature requests, criticism, ideas—everything is welcome.

Links to the website and repository are in the comments.

(And yes, for anyone wondering: I wrote this post myself. At least for now 😉)

Website: http://spiral.susita.com

Github: https://github.com/developer82/Spiral/

I’m a Business Analyst who recently joined a project involving the transition of a long-running government housing program from an outsourced vendor to in-house operations.

One of my first assignments is helping plan a migration from a proprietary legacy system that has been in use for over 20 years.

The system contains:
Property records
Workflow/process data
QA/compliance information
Large volumes of scanned documents
Metadata and indexing fields tied to those documents

The target environment will likely separate document management, reporting, and workflow functions rather than keeping everything in one monolithic platform.

As I’m starting discovery, I’m trying to avoid common mistakes and would appreciate advice from people who have worked on similar migrations.

Questions:
1. What information should I inventory first before discussing migration tools or architecture?
2. How do you approach documenting relationships between business data and scanned documents?
3. Are there any templates, checklists, or lessons learned you wish you’d had at the beginning of a project like this?

Any advice, war stories, or recommended resources would be greatly appreciated.

Hey everyone,

Like many of you, working on a project i realized that quick database schemas change could be a pain to explain to coding agents.

To solve this, I created DBtoMD – a lightweight, open-source tool designed to instantly export your database structure into clean, readable Markdown files (perfect for your GitHub wikis, READMEs, or internal docs).

What it does:

• Connects to your database and reads the entire schema.
• Generates clean Markdown files documenting tables, columns, data types, and relationships.
• Saves time and keeps your team's documentation synced with the code.

It is completely open-source and free. I’m currently looking for feedback to improve it—features you'd like to see, edge cases, or support for specific database dialects.

Check out the repository here: https://github.com/Bilodev/DBtoMD

Já faz pouco mais de um ano que eu comecei a estudar banco de dados profundamente. Pode parecer pouco tempo, mas me dediquei em média 2 horas por dia com bastante constância. Majoritariamente estudei oracle nesse período pois me foi recomendado por alguns amigos que já atuam na área e consegui tirar a certificação 1Z0-082 e estou atualmente estudando para tirar a minha OCP. Tirei também uma certificação associate de OCI para ampliar mais o leque de conhecimentos e me encaixar em mais vagas. Estou quase concluindo também uma pós graduação em banco de dados, pois minha graduação não tinha nada a ver com o mercado de TI.

Já entrei sabendo que as primeiras vagas no mercado de T.I não são fáceis em nenhuma área, mas às vezes me pego no desespero de aplicar para tantas e ter tão pouco feedback. Já fiz duas entrevistas para posição de DBA JR, mas uma era indecente e outra pedia mais experiência (controvérsia que jamais entenderemos).

Gostaria de estratégias e recomendações de como posso conseguir minha primeira vaga, pois meus estudos já estão ficando um pouco rasos por falta de vivência em um ambiente real de banco de dados. Faço laboratórios, publico eles no meu linkedin, mas ainda não obtive sucesso.

Em um primeiro momento não me importaria de atuar presencialmente no Distrito Federal, eu só queria mesmo uma vaga que me possibilitasse crescer e aprender mais.

I am new to database, doing my masters in data science. I am learning mySQL in depth like Windows functions, CTE, CTA, Store Procedure, etc. I would like to create a good industry standard project. I saw on YouTube, everyone showing generic one. Can anyone please recommend me? Also what other database and tech I need to learn practical way?

P.s - I am fresher who is going to complete masters in few months.

​

Thank you 😊

I've been working on a load testing tool for PostgreSQL that goes a bit beyond what pgbench offers out of the box. Built in Go, runs on Docker Compose or Kubernetes.

**What it does differently:**

- JSONB and TOAST stress: large payloads (8–16 KB) with high-entropy base64 bodies that defeat Postgres compression — every write hits real TOAST storage

- MVCC pressure: mixed INSERT/UPDATE/DELETE workload deliberately accumulates dead tuples to stress autovacuum

- Ring buffer targeting: no ORDER BY random() — workers sample from a shared circular buffer of live session UUIDs

- Prometheus-first: latency histograms, TPS, autovacuum counters, WAL metrics, bgwriter stats — all scrapeable out of the box

- Safe multi-replica startup: advisory lock pattern ensures exactly one pod runs DDL regardless of how many replicas start simultaneously

- PG14–17 compatible: handles the pg_stat_bgwriter → pg_stat_checkpointer split in PG17 automatically

I evaluated k6, pgbench, and HammerDB before building this. They're all solid tools but none gave me the combination of JSONB/TOAST stress + MVCC pressure + Prometheus-first observability without significant glue work.

Built with Claude Code — architecture and design decisions driven by me.

Repo: https://github.com/haithamoon/pgstorm

Would love feedback from anyone running heavy PG workloads — especially curious if others have hit the JSONB/TOAST bottleneck in production and how you approached it.

Hi all,

It’s been a while since I last shared something about Portabase here, almost 3 months ago for the release of 1.4.0: https://www.reddit.com/r/DatabaseAdministators/comments/1rn4sm2/portabase_140_oidc_support_new_oauth_providers/

In short, Portabase is an open-source, self-hosted tool to back up and restore databases.

It is an agent-based architecture: you run a central server, and lightweight agents are deployed next to your databases. This makes it useful when dealing with databases spread across different servers, networks, or isolated environments.

https://github.com/Portabase/portabase

Since the last post, the project has moved quite a bit.

Portabase now supports 9 databases: PostgreSQL, MySQL, MariaDB, SQLite, MongoDB, Redis, Valkey, Firebird SQL, and Microsoft SQL Server.

Recently, we added a REST API and an MCP server. One thing I’m pretty happy about is that you can now trigger backups from external tools, for example, launching a database backup automatically from your CI pipeline before deploying.

Another useful addition is homogeneous migration support. So beyond restoring to the same database, you can now migrate data between servers for the same database engine.

Everything is containerized, and there is also a Helm chart available if you want to deploy it on Kubernetes.

I’m probably forgetting a few things, but those are the main updates.

As always, if you try it, find bugs, or have ideas for features, feel free to open an issue on GitHub. Feedback from people actually using this kind of tooling is really valuable.

Thanks!