If your “database ticket” says “it’s slow” or “it timed out,” you’re not asking for help … you’re asking someone else to guess.

I’ve watched good database engineers (DBAs) lose days to vague reports that are basically “something happened” with a request for help. Not because teams are careless, but because nobody taught them what DBAs actually need to investigate: the query, the error, the timing, and the context.

DBAs want to be helpful. But their expertise is best used when developers can solve common issues independently and escalate the non-obvious ones with enough evidence to act.

The fastest way to get database help is to show up prepared: query + full error + timestamp + environment + what changed.

Prepare, Investigate, Report

I think about working with database teams as a simple framework: Prepare, Investigate, Report.

The point isn’t to turn every developer into a DBA. It’s to stop treating the database like a black box. When you understand how your database behaves, you write better code, you debug faster, and you know when you’re holding a lock across an API call.

Prepare

How do you prepare for an issue? You read one good book for your chosen database, subscribe to a few database blogs, and experiment in a sandbox where you can break things safely.

Learning is how you prepare to handle issues.

You need to understand what your database will do with your queries. Learn how transactions and locking work. Learn what an index actually changes. As a stretch goal, learn how to run EXPLAIN (or your database’s equivalent) so you can see the plan that will be used.

Also learn how to view table and index definitions for your database. It keeps you from guessing about schema, keys, and constraints while you’re trying to debug. And for some errors it’s the key to solving problems on your own (missing table, column, or wrong datatype).

The same tool you use to query your database can usually describe objects using catalog tables. Those catalog tables contain metadata about the database: tables, indexes, columns, types, foreign keys, triggers, procedures, functions, and more.

While you can query these catalog tables directly, tools like DBeaver can format the results into a tree view or DDL (data definition language).

You should also know how to capture and log SQL error messages in a way that lets you find them again.

Investigate

Try to make progress independently first. Most database issues aren’t “database issues” … they’re application behavior running into rules enforced by the database. Primary keys and unique indexes blocking duplicates. Column data types blocking storing the wrong type or length of data. Locking enforcing isolation between concurrent transactions. Or maybe your insert is firing a trigger a former co-worker requested to ensure that there are no orphaned rows without parents in other tables.

Start with the error itself. Look for an SQLSTATE/SQLCODE, error code, or constraint name. Those details usually tell you whether you’re looking at syntax, permissions, data integrity, deadlocks, timeouts, or a resource limit. And they are easily searched for on Google.

Digging into errors will make you a better developer. You’ll learn what’s wrong with your code and how to avoid the same class of error next time.

Report

If you need help, be a good reporter. Include:

  • Who (ID)
  • What (full error message and SQL)
  • When (date/time in UTC)
  • Where (host and database name)

If you include these, you make it possible to answer the fifth “W” … Why?

It’s fair to say this feels like paperwork, but the alternative is worse: a wild goose chase with everyone guessing what to look at.

Before You Escalate

If you’re about to contact your database team, ask yourself:

  • Do I have the exact SQL and parameters that ran?
  • If there was an error, do I have the full error, and have I tried looking up the SQLCODE/SQLSTATE?
  • Do I know the transaction boundary … where it begins and where it commits?
  • Do I have an EXPLAIN plan (or at least row counts and indexes involved)?
  • Do I have a timestamp and environment?
  • Did anything change … not whether anything you think is related changed, but whether anything changed.

If you can answer those, you won’t just get faster help. You’ll often solve the problem yourself.

The framework here covers the self-service side. But when things get harder — deadlocks, timeouts, hidden triggers — the problem is usually contention, and it lives in your application code.