When the system drags, the line is always the same: "the ERP is slow". But most of the time, the ERP is just the messenger — the real bottleneck sits beneath it, in the database. And the database is a silent problem: it degrades little by little, unnoticed, until the day a close that took minutes starts taking hours.
The good news: almost every database performance problem has an identifiable cause and a known fix. This article maps the most common ones — and shows what a DBA does to fix the root cause and speed things up, instead of just "buying more hardware".
How to Know the Problem Is in the Database
Before blaming the system, watch for the classic signs of a database bottleneck:
- Rising response times on screens and reports that used to be fast;
- Blocking chains — one session blocking many, creating the "everything stopped" feeling;
- CPU, memory or
I/Ospikes at specific times (close, integrations, heavy reports); - Slowness that worsens over time as tables grow.
The Most Common Database Problems (and What the DBA Does)
1. Slow queries and bad SQL
It's the number-one cause. Queries that apply functions to columns (filtering by UPPER(name) or YEAR(date)), use a leading wildcard (LIKE '%text') or overuse correlated subqueries prevent index usage and force row-by-row reads.
What the DBA does: identifies the costliest queries from the database cache and rewrites or tunes the heaviest ones.
2. Missing or poorly designed indexes
Without the right indexes, the database scans entire tables to answer a simple query. Too many (or duplicate) indexes also hurt, since they make every write more expensive.
What the DBA does: maps missing and redundant indexes, creates what's needed and removes what only gets in the way.
3. Outdated statistics
The optimizer chooses the execution plan based on statistics. When they're stale, it picks bad paths — and the same query that flew yesterday crawls today.
What the DBA does: keeps statistics-update and index-maintenance routines, restoring predictability to the optimizer.
4. Locks and contention
A transaction that's slow to release an object blocks everything behind it. The user feels "slowness", but the problem is waiting, not processing.
What the DBA does: identifies the blocking session, analyzes why it's slow and adjusts transactions and isolation to reduce contention.
5. I/O and disk bottlenecks
Disk waits (logs like WRITELOG and PAGEIOLATCH) signal that storage can't keep up. Keeping data and transaction log on the same volume, or a misconfigured tempdb, makes it worse.
What the DBA does: separates data, log and tempdb, tunes memory configuration and sizes storage for the real I/O.
6. Inadequate memory and configuration
Insufficient RAM forces the database to reread from disk constantly. And many instances run with "factory" parameters, far from ideal for the real workload.
What the DBA does: tunes instance memory and parameters — often with meaningful gains (reports cite 20–30%) from configuration alone, with no hardware spend.
7. Growth without partitioning or archiving
Tables with hundreds of millions of rows, with no partitioning or archiving policy, make every operation exponentially more expensive.
What the DBA does: implements partitioning, archiving and controlled purging, keeping the database lean and fast.
8. No monitoring and unreliable backups
Finding the problem only when users complain is too late. And a backup without a restore test is a false sense of security.
What the DBA does: deploys continuous monitoring with alerts and backup policies with periodic restore tests and defined RPO/RTO.
Tuning Isn't "Buying More Hardware"
Many companies' reflex to slowness is a bigger server. Sometimes it's needed — but rarely as the first step. Tuning indexes, statistics, queries and configuration usually solves most cases, with strong gains at near-zero cost. Hardware without tuning is money masking the symptom; the problem returns.
Database performance isn't luck or brute force: it's method. Measure, find the root cause and fix — in that order.
Why a Dedicated DBA Is Expensive — and What DBA as a Service Is
A senior DBA is expensive to hire and retain, and in most companies sits idle between crises. At the same time, leaving the database without specialized care is too risky. DBA as a Service solves that dilemma: you get monitoring, tuning, backup and high availability on demand, with guaranteed seniority and no fixed hiring cost. It's the same logic as on-demand support, applied to the database — and tied directly to IT cost reduction.
How Vanquish Code Speeds Up Your Database
Vanquish Code is a full-service IT company: beyond Protheus support and Agentic AI, we have a specialized DBA team. In DBA as a Service:
- SQL Server, Oracle, PostgreSQL, MySQL and MongoDB — plus expertise in the Protheus (TOTVS) data model.
- 24/7 monitoring with alerts before problems become incidents.
- Performance tuning — execution plans, indexes, statistics and parameters.
- Backup & recovery with restore tests and high availability.
- Cloud migration (Azure, AWS, GCP) with cost optimization.
Conclusion: the Database Is the Foundation — Care for It
The database is the invisible foundation of your ERP and systems. When it struggles, everything struggles with it — and blaming "the system" only delays the fix. Identifying the root cause, applying real tuning and keeping the environment monitored is what turns a slow database into a fast, reliable base.
Vanquish Code puts your database in specialized hands, on demand. Start with a free diagnosis and discover where the bottleneck is — and how much faster you can go.