It was a great vacation, packed with long walks, beach time, fun, and rest.

I came back to work rejuvenated, knowing I’d need a few days to get back into the working rhythm. Most of the day was spent catching up with colleagues and the latest news.

One was about a brand-new data center, ready to go live in just a few days.

“Production-ready” turned into “data-empty”

“It turns out delivering new data centers is becoming almost routine,” I thought to myself, feeling as light as a breeze.

After catching up with my colleagues, I was greeted by a mountain of unread emails. Honestly, I can’t tackle that for hours without feeling my will to live slowly evaporate. So, I decided to shift my focus and check out the new data center, just to see how everything was set up…

My fresh bronze tan didn’t help – I went pale as a ghost: one of the key databases in our shiny new “production-ready” data center was completely empty.

No data. Nothing. Niente. Nada.

The problem? We needed a full month of historical data available FROM DAY ONE. And all we got were… good vibes and positive energy.

Two days, no data, one hero

The clock was ticking. We had maybe two days (probably less) until go-live. Yes, it was an emergency, and no, there wasn’t a second to waste.

We turned to our trusty old Replay app, hoping it could save the day.

And once again – it delivered!

The shining star of our toolkit, Replay came through, regenerating over a month’s worth of data before the deadline.

In the end, the data was restored, the deadline met, and our sanity… mostly intact. But one thing was clear: returning from vacation had never felt more like a horror story. And you? Keep your tools close and your backups closer.

The post The Day Our Data Center Went Ghost appeared first on ShiftMag.

Picture this scenario: You’ve just joined a new tech company, excited to start onboarding and dive into your first projects. But soon, it hits you – the tension.

Developers gripe about sluggish and obstructive DBAs, while Database Administrators grumble and murmur about the constant stream of poorly optimized queries, chaotic code, and last-minute demands from developers.

Did you stumble upon a toxic workplace? Not exactly. It’s the age-old clash that’s been brewing for decades between two ‘tribes’: those who want to build quickly and those who safeguard stability.

So, do DBAs play the role of protectors, or are devs just a tad bit spoiled?

How did we get here?

The friction comes from a classic disconnect: speed vs. stability.

Developers are eager to ship features as fast as they can (preferably yesterday), often under pressure from clients, management, or some other deadline-driven force, while DBAs are focused on ensuring the database doesn’t crash tomorrow.

When these priorities clash, chaos is inevitable – and I know this firsthand because I’ve been on both sides.

Let’s take a closer look at it from a developer’s angle

• ‘We need to speed up our delivery!’

The main argument is that developers often work under tight deadlines. To them, a database is just a tool – the simpler, the better. Why involve DBAs early if it slows down prototyping?

There’s also a prevailing ‘good enough for now’ mentality, where getting a working prototype is the priority.

• ‘Setting up new databases takes ages.’

Waiting for approvals, scheme checks, or infrastructure setups feels like watching paint dry.

• ‘Getting DBAs involved can feel like pulling teeth.’

When DBAs push back on quick fixes or demand documentation, developers see red tape rather than guardianship.

Now, let’s dive into the DBA’s side of the story

• ‘We’re called in too late!’

DBAs often inherit poorly designed schemas or performance nightmares. Fixing a burning database at 2 a.m. is never fun, especially when you don’t know anything about it or where to begin.

• ‘Devs don’t listen.’

Recommendations about indexing, query optimization, or security often fall on deaf ears – until an outage happens. No matter how many times you share documentation, hold knowledge-sharing sessions, or discuss the topic, it sometimes feels like no one listens.

• ‘We’re the unsung janitors.’

While devs chase innovation, DBAs clean up the mess. Their priorities – backups, scalability, and compliance – may not be glamorous, but they’re non-negotiable.

If a company wants to make it in the worldwide market, it needs to be compliant with numerous regulations. And that is just the beginning – data needs to be secured, and data leaks and privacy concerns aren’t fun for anyone. We need backups and replication set up for disaster recovery, satisfy numerous architecture decision records, and all that complicates the process. It will never be as simple and fast as just deploying a DB locally in Docker.

So, what do devs and DBAs really want?

DBAs just want preventative care – they’re like doctors urging you to eat your veggies, not just treating heart attacks.

On the other hand, devs need speed without fallout. They want to innovate without waking up to a dumpster fire.

But do devs really want to own databases?

Sure, devs can deploy their own database, but maintaining performance, security, and costs? That’s a full-time job – one many devs aren’t signing up for.

It may sound great at first, but once you deploy it, the database works fine – until it doesn’t. It’s just a matter of time before the first issues arise. And surely, devs would rather spend their time programming than maintaining and troubleshooting a database.

Think it can’t get worse? Well, say hello to AI

Enter AI and vector databases – tools promising lightning-fast analytics.

The number of new vector databases is skyrocketing, and devs want them all, each with a specific feature they need. But for DBAs, this is a nightmare. Integrating a new database is a slow and painful process, as all checks for security, compliance, and requirements need to be tested and approved. New database types (e.g., vector DBs for ML) often lack mature tooling or expertise. DBAs scramble to secure and scale them, while devs resent the learning curve.

So, who is right?

They both are, and at the same time, they both aren’t – much like the relationship between devs and clients.

Devs often complain about clients’ broad demands, tight deadlines, and constant changes. Sound familiar? The Dev vs DBA battle is similar: devs forget that, as clients of DBAs, they’re the ones pushing for deadlines and changes, just like clients do to them.

So, devs must make compromises with clients because the company’s revenue depends on it. However, I think DBAs tend to be ‘harder’ on their clients since they don’t face the same pressure of potentially losing business.

Is there hope for peace?

There isn’t – at least not a simple one.

But we can all work together to reduce tension and aim for some kind of truce. We need to be more understanding.

Devs should recognize that DBAs aren’t just complicating things for no reason and should involve them in the service architecture process. On the other hand, DBAs should view devs as clients, understand the need for compromise, and simplify the process of providing databases by using automation or internal tools whenever possible.

The post Devs and DBAs can’t find peace, but could they call a truce? appeared first on ShiftMag.

Can you even be a software engineer if you don’t understand databases?

You can create a simple script or even an application without a database, but the reality is that databases enable data storage, retrieval, and analyses crucial for modern software applications.

Wei Hu from Oracle, the company that brought the first commercial relational database to market in 1979, says that the right way to choose how your app will store data is to think about what happens if it becomes very successful and you have to scale it.

In this video, Hu explains the three approaches to organizing and storing data and how to choose the one that is right for you:

This video is a part of ShiftMag’s video series, Engineer Explains.

We asked experienced engineers to share how they would explain some basic and some less basic tech terminology to different job tech job titles or at three levels of experience – from junior developer to CTO.

More:
How would you explain APIs, internal developer platforms, software architecture, software testing, scaling infrastructure without breaking the bank,  low-code as a dev tool, or full-stack framework at three levels of experience?

The post Engineer Explains: Database in 5 minutes appeared first on ShiftMag.