Most database performance problems do not begin with an obviously bad query. They begin with a reasonable schema that quietly stopped matching the application around it. A table accumulates columns for unrelated concerns, identifiers change meaning, reports compete with transactional work, and every new feature adds another conditional join.

Refactoring a relational database is not about chasing a perfectly abstract model. It is about preserving clear data boundaries while making common operations predictable, observable, and affordable. The fastest database is often the one whose structure makes the right query easy to write.

Start with workload, not normalization slogans

Normalization remains a valuable tool, but it is not a performance strategy by itself. A highly normalized schema can protect data integrity and still be slow for an important read path. Conversely, a denormalized table can make a dashboard fast while creating subtle consistency problems elsewhere.

Before changing tables, identify what the system actually does. Look at the operations that matter: user-facing requests, background jobs, API endpoints, imports, exports, and operational reports. For each one, ask what it reads, what it writes, how often it runs, and what “slow” means to its caller.

• Which queries occur on every request?
• Which tables grow continuously?
• Which joins or sorts process more rows than expected?
• Which writes hold locks long enough to affect other work?
• Which data is needed immediately, and which can be computed asynchronously?

This turns a vague refactor into a set of engineering decisions. A rarely used administrative report deserves a different design trade-off from an API query on a busy request path.

Give every table one clear responsibility

Enduring schemas make relationships explicit. A customer is not also an order address, an audit log, and a collection of ad hoc settings stored in spare nullable columns. When a table represents several concepts at once, the application eventually needs rules that the database cannot express clearly.

Consider an order table with shipping_address, billing_address, customer_notes, and several status timestamps. Keeping an immutable address snapshot on the order may be exactly right: historical orders should not change when a customer edits a profile. But placing unbounded event history or a growing set of delivery attempts in that same row creates a different problem. Those are one-to-many relationships and should usually have their own tables.

A useful test is to ask whether two fields always share the same lifecycle. If one can be created, updated, retained, or deleted independently of the other, they likely deserve separate modeling. This improves correctness first, but it also narrows rows, simplifies indexes, and reduces the amount of data carried through routine queries.

Index for the query you need to run

Indexes are not a checklist of foreign keys and frequently filtered columns. They are data structures that must serve a query shape. An index that helps one predicate may do little for a query that filters, orders, and paginates differently.

Suppose an endpoint retrieves recent paid orders for one account:

SELECT id, total, created_at
FROM orders
WHERE account_id = ?
  AND status = 'paid'
ORDER BY created_at DESC
LIMIT 50;

An index beginning with account_id, then status, then created_at is a natural candidate because it follows the filtering and ordering pattern. The exact effectiveness still depends on the database engine, data distribution, and query plan, so verify it with the engine’s explain facility rather than assuming.

Also treat indexes as write costs. Every inserted or updated row may need changes to several index structures. Adding an index can be a strong improvement for a critical read, but adding every conceivable index can turn routine writes into the next bottleneck.

Make pagination intentional

Offset pagination is easy to adopt:

SELECT id, created_at
FROM orders
ORDER BY created_at DESC
LIMIT 50 OFFSET 10000;

At larger offsets, the database may still need to walk past many rows before returning the requested page. For chronological feeds, keyset pagination is often a better fit. Store the final row’s ordering values as a cursor and request rows after that position. Use a stable tie-breaker such as the primary key when timestamps can match.

SELECT id, created_at
FROM orders
WHERE (created_at, id) < (?, ?)
ORDER BY created_at DESC, id DESC
LIMIT 50;

The corresponding index should reflect that ordering. More importantly, the cursor defines a stable traversal model rather than an increasingly expensive skip operation.

Separate transactional truth from read convenience

Relational design does not require every screen to reconstruct its answer from the most normalized tables at request time. A checkout flow needs transactional correctness. A management dashboard may need totals, trends, and grouped counts across large histories. Those workloads should not automatically share the same query strategy.

For expensive, repeatable reads, consider a derived table, summary table, or materialized view where the database supports it. The key question is not whether denormalization is “allowed.” It is how the derived data is refreshed, how stale it may become, and what happens when refresh work fails.

Make those rules explicit. A summary updated in the same transaction provides one consistency model. A background process that updates it later provides another. Both can be valid, but neither should be accidental. Keep the original transactional records authoritative, and make the derived representation rebuildable.

Refactor safely with an expand-and-contract migration

Database refactors are deployments, not isolated schema edits. A running application, workers, scheduled jobs, and rollback paths may all encounter the old and new shape at different moments.

The safest general approach is expand and contract:

1. Add new tables, columns, or indexes without removing the old structure.
2. Deploy code that can write the new representation, often while remaining compatible with the old one.
3. Backfill existing rows in controlled batches, with monitoring and retry-safe behavior.
4. Validate counts, constraints, query results, and application behavior.
5. Switch reads to the new structure once it is complete and trusted.
6. Remove compatibility code and obsolete schema only after the transition window has passed.

Batching matters because a huge update can create long transactions, contention, replication pressure, or an unexpectedly large rollback. Make the backfill resumable. Record progress through an immutable key range or another reliable checkpoint, and ensure rerunning a completed batch does not corrupt data.

Put integrity rules where they can be enforced

Application validation is necessary, but it is not enough to protect shared data. Multiple services, scripts, import tools, and future code paths may write to the same database. Primary keys, foreign keys, unique constraints, and appropriate nullability document the model while preventing invalid states.

Constraints should support real business rules, not wishful ones. A unique constraint on an external provider identifier can prevent duplicate imports. A foreign key can prevent orphaned child rows. A check constraint can protect a bounded state where the engine supports and enforces it. Each rule reduces the number of defensive branches every application query must carry.

Measure after every meaningful change

A refactor is successful when it improves the workload, not when the diagram looks cleaner. Compare query plans, execution times, row counts, lock behavior, and error rates before and after a change. Test with representative data volume whenever possible; small local datasets often hide the cost of a sort, join, or missing index.

The durable lesson is simple: model data for its truth, shape access for its workload, and evolve both with reversible steps. A relational database stays fast when its schema remains understandable enough that the next engineer can see not only what the tables contain, but why they are built that way.