“The CRM is slow” is a symptom, not a diagnosis. When the database is the cause, the culprit is usually a handful of queries doing far more work than they need to. Finding them is a matter of method, not genius.

This guide assumes you have access to the database behind a CRM you host or customise, such as PostgreSQL or MySQL. On a fully managed CRM you will not see the queries directly, but the principles still explain why some reports, filters and list views are slower than others, and what to ask your vendor or consultant.

Step one: capture, do not guess

Enable the database’s slow query logging or its built-in statistics view, and let it collect during normal business hours. Check the engine’s current documentation for the exact setting names.

You want two rankings, because they point at different problems:

• Slowest individual queries, which are the ones users feel as a hang.
• Queries with the largest total time, meaning cheap queries run constantly. A query taking a few milliseconds but running a million times a day can hurt more than a rare slow report.

Start with whichever list has the clearest offender. Resist the urge to tune the thing someone complained about unless the data agrees.

Step two: read the plan

Ask the database how it executes a suspect query, using its explain facility. You are looking for a few telltale signs:

• Full table scans on large tables, where the database reads every row to find a few.
• Sorting large result sets in memory or on disk because no index provides the order.
• Joins that multiply rows before filtering them.
• Big gaps between estimated and actual rows, a sign that statistics are stale.

Do not be intimidated by the output. Read from the most deeply indented step outward and look for the step that takes the most time or touches the most rows.

Step three: choose the fix

Most CRM slowdowns trace to a short list of causes.

Missing indexes. If a query filters or joins on a column that has no index, the database scans. Adding an index on that column, or a composite index matching the filter and sort together, can change the plan dramatically. Column order in a composite index matters: put the equality-filtered columns first, then range or sort columns.

Indexes that cannot be used. Wrapping a column in a function, for instance lower-casing an email in the query, can prevent a normal index from helping. Either store a normalised value or create an index matching the expression, if your database supports it. Leading wildcards in text searches, such as matching on “%smith”, defeat ordinary indexes as well; consider a proper search index.

Fetching too much. Queries that select every column, or load whole histories when a screen shows ten rows, waste time and memory. Select only what is needed and paginate.

N+1 patterns. Custom code that runs one query per record in a loop, such as one lookup for each of five hundred contacts. Replace it with a single query using a join or a batch lookup.

Stale statistics or bloat. The planner makes poor choices if it has outdated information about table sizes, and heavily updated tables can accumulate dead space. Routine maintenance such as analyzing tables and, where appropriate, vacuuming or rebuilding indexes keeps plans sensible.

Heavy reporting on the live database. A long analytic query competing with users entering data causes locks and slowdowns. Run reports against a read replica or an extract.

Indexes are not free

Every index speeds some reads and slows writes, since each insert or update must maintain it. They also consume storage and memory. An index added “just in case” is a cost without a benefit. Check periodically for indexes that are never used, using your database’s usage statistics, and drop them after confirming with the team and observing a full business cycle.

A quick triage table

Symptom	Likely cause	First thing to check
Contact search hangs	Leading wildcard or function on column	Query plan for the search statement
Report slow only at month end	Large date range scan, no supporting index	Index on the date and filter columns
Whole system slows during a report	Reporting competing with transactions	Run the report on a replica or extract
Page load slow, many tiny queries	N+1 pattern in custom code	Query counts per request
Fast last year, slower now	Growth, stale statistics	Table sizes, last analyze time
Sudden slowdown after a release	Changed query or dropped index	Compare plans before and after

A hypothetical

A team complains that opening an account page takes several seconds. The slow log shows the page triggers about two hundred small queries, one per related contact, each filtered on an unindexed foreign key column. Adding the index on that column makes each lookup fast, but the real fix is changing the code to fetch all contacts in one query.

After both changes, the page makes a handful of queries instead of hundreds. They test in staging with realistic data volume, because an index that looks great on a thousand rows can behave differently on millions, then release it during a quiet window with the previous plan documented in case they need to compare.

Safety rules for production changes

• Test the fix on a copy with production-sized data.
• Create indexes in a way that does not lock the table, if your database offers it; check current documentation.
• Change one thing at a time and measure.
• Record each change, its reason and the before-and-after timings.
• Keep a way back, such as dropping a new index if writes suffer.

Frequently Asked Questions

How do I know the database is the bottleneck? Compare application time against database time for a slow request. If most of the time is spent waiting on queries, tune the database. If not, look at application code, network or integrations.

Should I index every column used in a filter? No. Index the columns used in your most frequent and slowest queries, ideally guided by the slow log. Too many indexes slow writes.

Is adding more CPU or memory a fix? Sometimes it buys time, but a bad query on bigger hardware is still a bad query. Fix the query first, then size the hardware.

How often should I review slow queries? Monthly is reasonable for a busy system, and after every significant release or data import.

What if the CRM is managed and I cannot see queries? Capture which screens, filters and reports are slow, with timings and examples, and bring them to the vendor. Narrower filters, fewer columns and scheduled reports often help from the user side.

Next Step

Turn on slow query logging or statistics in a staging environment, run a normal day’s workload against it, and pick the single query with the highest total time. Read its plan and write down what you would change before touching anything.