When a business takes on a new database, the first priority isn't performance tuning or adding indexes—it's making sure the data can be recovered if something goes wrong. That's the starting point for Lucas Almeida of CloudFogg, a database and cloud services firm recently featured in a roundup of database administration partners. In this interview, Almeida walks through the fundamentals of database health, the hidden traps of cloud migration, and why the DBA role is evolving rather than disappearing.
Start with the Fundamentals
When CloudFogg takes on a new client, the first thing they look at isn't the slowest query or the most complex schema. It's the basics: availability, backups, recoverability, performance, and capacity. Almeida emphasizes that backups and recovery are always the priority.
"We have worked with companies facing critical situations because they discovered, after a database corruption or failure, that they didn't have a reliable backup they could restore from."
He notes that having a backup job that reports "successful" isn't enough. The real question is whether those backups can actually be restored within the business's recovery objectives. From there, CloudFogg examines CPU, memory, storage, I/O, database growth, long-running queries, blocking, failed jobs, and whether proper monitoring and alerting are in place.
"A database can appear healthy simply because nobody is looking closely enough," Almeida says. The goal is to establish a baseline, understand recovery requirements, and identify the biggest operational risks before optimizing anything.
The Hidden Trap in Cloud Migrations
Cloud migrations often hit unexpected snags, and Almeida says the biggest one is dependencies. Databases rarely operate in isolation, especially in large environments.
"Teams naturally focus on moving the database, but databases rarely operate in isolation."
He points to database replication as a major example, particularly in Microsoft SQL Server environments where replication, CDC, linked servers, ETL processes, and reporting platforms create complex dependencies. Another common problem: companies don't always know who is using their data. Almeida describes an environment where a 55 TB table was being replicated to eight SQL Server subscribers—even though the original application had been decommissioned two years earlier. Another business process was still consuming that stale data, and the teams involved weren't aware of the dependency.
CloudFogg implemented SQL Server auditing to identify which applications were still accessing the table, removed the stale usage, and ran a one-month "scream test" to ensure no unidentified consumers remained. The lesson: discovery and auditing are critical before any migration.
"Before migrating, we want to understand not only what data exists, but where it comes from, where it goes, who uses it, and whether it still needs to exist at all."
Performance Tuning: Evidence Over Guesswork
When a client reports a slow query, CloudFogg's first step is to determine whether the query itself is the problem or a symptom of something else. They use tools like SolarWinds DPA, Quest Foglight, Datadog, and native tools like SQL Server Query Store and Google Cloud Query Insights.
"Looking at a query only at the moment it's slow doesn't always tell the full story," Almeida explains. Historical data allows them to compare current behavior against previous execution plans, wait times, and resource utilization. From there, they analyze execution plans, wait statistics, blocking, indexes, and infrastructure resources—working from evidence rather than immediately adding an index or rewriting the SQL.
"Our goal isn't simply to make one query faster. We want to understand why it became slow, identify the actual bottleneck, and fix the root cause without creating performance problems somewhere else in the environment."
The Growing Demand for PostgreSQL and Managed Services
CloudFogg's strongest experience is with relational databases: Microsoft SQL Server, PostgreSQL, MySQL, and Oracle, as well as cloud-managed platforms on AWS, Azure, and Google Cloud. Almeida sees particularly strong demand for PostgreSQL and managed cloud database services.
"PostgreSQL was once more commonly associated with smaller applications, but that has changed significantly," he says. Today, it's being adopted for large-scale, business-critical workloads, including services like Amazon RDS for PostgreSQL and Azure Database for PostgreSQL.
At the same time, database administration is becoming more connected to automation, infrastructure-as-code, observability, and AI. Almeida sees this as an opportunity, not a threat.
"The DBA role isn't disappearing; it's evolving," he says. Companies still need deep database expertise, but increasingly they expect that expertise to include cloud architecture, automation, observability, AI-assisted operations, security, reliability, and cost optimization.
One Change for Businesses Without a Dedicated DBA
For businesses running databases without a dedicated DBA, Almeida's advice is clear: implement proper monitoring and make sure backups are actually recoverable.
"A lot of smaller companies have backups configured, but nobody regularly verifies that they're completing successfully or, more importantly, that the databases can actually be restored," he says. A successful backup doesn't mean you have a successful recovery strategy—that's a dangerous assumption to discover during an outage.
The same applies to monitoring. You don't need someone watching a dashboard 24/7, but you do need visibility into failures, storage growth, performance degradation, blocking, and backup status. Almeida suggests using observability platforms like Datadog, database-specific monitoring products, or even building a framework with PowerShell or Python.
"The important part isn't necessarily which tool you choose—it's having reliable monitoring, meaningful alerts, and a process for responding when something goes wrong."
For more insights from CloudFogg on database administration and cloud services, visit their website.