Insights2 February 2025Updated 25 October 20265 min read

Database Normalisation for Cost-Effective Cloud Infrastructure

Taming the cloud database normalisation for cost effective infrastructure with a robotic hand reaching towards a digital cloud.

Database normalisation addresses repeated facts and the inconsistencies that arise when those facts change. It is a data design technique, not evidence that a cloud bill will fall. Redgate's explanation of normalisation starts with reducing redundancy and avoiding update anomalies. We recommend treating any cost saving as a separate hypothesis to test.

That distinction changes the brief for an infrastructure review. Instead of asking an engineer to normalise everything and promise savings, ask which repeated facts cause trouble, which queries matter, and what measured result would justify the migration. Keep correctness and cost as separate acceptance tests.

Start with the fact that belongs in one place

Consider a hypothetical field-service database. Each inspection record includes a customer's identifier, current address and contact details. If the intended meaning is the customer's current address, our proposed design would keep that address in a customer record and refer to it from inspections. The example illustrates the update-anomaly problem, rather than a measured customer deployment.

Before changing that design, ask whether the address is current contact information or a record of where the inspection took place. We would preserve the latter as historical evidence. Do not remove repeated values until the team agrees that they represent the same fact.

Normal forms give that discussion a more precise vocabulary. Redgate describes first normal form as single, atomic attribute values. For second normal form, the relation must already be in 1NF, and no non-prime attribute may depend functionally on a proper subset of any candidate key. A non-prime attribute belongs to no candidate key. Redgate's third-normal-form discussion addresses transitive dependencies involving non-prime attributes. Use that discussion to review the relationships, rather than treating a larger number of tables as a success measure.

Make the relationships enforceable

A diagram is not the acceptance test. In PostgreSQL, a primary key identifies rows through values that are unique and not null. A foreign key constrains referencing values to match a referenced row, subject to the rules for null values. These are database rules, not a substitute for deciding what the records mean.

For the hypothetical customer design, we would test that an inspection cannot refer to a customer that does not exist. Where every inspection must have a customer, make the reference mandatory. PostgreSQL documents that nullable referencing columns can escape the foreign-key check, so a foreign key alone does not express that requirement.

Write the deletion behaviour into the migration brief too. Should a customer with inspections be deletable? Should contact information be removed while inspection evidence remains? Those are decisions for the organisation, not details to leave to whichever default the implementation happens to use. We recommend agreeing the expected result before writing the migration.

Do not assume that fewer repeated values means faster queries

PostgreSQL's index documentation explains both sides of an index: it can retrieve particular rows faster, but it adds overhead to the database. Its discussion of index combinations also makes the choice depend on which queries are common and how often the table is updated.

Use that trade-off when reviewing a proposed schema. Ask for the query that retrieves an inspection with its customer details, alongside the query that updates a customer's address. Review the proposed indexes against both. Do not approve an index merely because the new diagram contains another relationship.

For our cost review, we would record table and index storage separately, then compare the same operations before and after the change. Keep data volume, query parameters and test conditions in the evidence. A schema proposal without a workload comparison is not enough for us to recommend reducing provisioned capacity.

Measure execution, then decide what to pay for

PostgreSQL's EXPLAIN documentation distinguishes the planner's estimates from actual execution. With the ANALYZE option, EXPLAIN executes the query and reports actual row counts and timings. The BUFFERS option adds information about buffer activity.

Use those tools on an isolated test copy for the migration review. Start with representative reads and writes, not a single convenient lookup. Record the plan and its execution measurements, and measure ordinary end-to-end operation time separately before comparing with the baseline. PostgreSQL notes that EXPLAIN ANALYZE adds measurement overhead and does not include network transmission to the client. Investigate a large difference between estimated and actual row counts before accepting the result.

Be careful with the command itself. PostgreSQL warns that EXPLAIN ANALYZE actually executes the statement and its side effects. Do not point a write test at customer data because the command sounds like inspection. Our recommendation is to keep these experiments away from production.

Only then review the commercial question. Ask which billable resource the proposal would let the organisation reduce, under its actual contract and capacity requirements. We would require both the workload evidence and that purchasing decision before putting a savings figure in a business case.

Keep reporting copies deliberate

A repeated value is not automatically a design mistake. PostgreSQL materialised views persist query results in a table-like form. Its documentation explains that access can be faster than querying the underlying tables, while the stored results may not be current.

For a reporting screen, consider that option separately from the authoritative records. Specify how old the report may be, who owns the refresh, and how users will see its freshness. We would not accept a reporting copy as the place where staff correct the underlying customer record.

For a legacy migration, start with one bounded relationship and a rollback plan. Compare the old and proposed outputs, test the agreed constraints, and review the workload evidence before expanding the change. The decision to proceed should name the inconsistency removed and the measured operational result, without promising a cheaper cloud bill from normalisation alone.

Update, October 2026

For teams using coding agents on schema changes, we recommend adding the agreed record meanings and migration tests to the agent's brief. Our engineering article What the Agent Does Not Know to Look For describes supplying code structure, dependencies and known gaps before planning begins. Use that preparation to make the database assumptions available for independent review.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →