Databases on Brian Faust

Replication Copies Corruption Too

Tue, 01 Sep 2026 00:00:00 +0000

The primary answers SELECT 1. So does its streaming standby. Their WAL positions show that the standby has caught up, and PostgreSQL promotes it without error. shipment-100 is missing from both.

Every infrastructure signal in that sequence can be true at the same time. The OPS-04 fixture makes it happen with PostgreSQL 18.1: a valid DELETE commits on the primary, reaches the physical standby, and survives promotion. Failover restores a writable endpoint, but the deleted shipment is still deleted. Replication worked perfectly. That is the problem.

A Valid Pricing Row Can Still Be Wrong

Sun, 15 Feb 2026 00:00:00 +0000

One row charges EUR 12 from zero through five kilograms. Another charges EUR 18 from four through ten. Give them different names and sequence numbers, attach them to the right tariff book, and both rows can be perfectly valid database records. At 4.5 kilograms, they still disagree about the base price. Adding them gives EUR 30, which nobody specified as the base rate.

Moving my private rating engine from expression definitions to explicit rows made this problem easier to inspect. It didn’t solve it by itself. I needed to decide which combinations should be impossible, which should remain valid drafts, and which should stop a ruleset from becoming executable.

Not Every Pricing Rule Belongs in a Formula

Sun, 01 Feb 2026 00:00:00 +0000

The first parcel costs EUR 20. Parcels two through ten cost EUR 5 each. After that, each additional parcel costs EUR 3. Twelve parcels should cost 20 + 9 × 5 + 2 × 3 = 71 euros. There is nothing particularly exotic about that tariff. Turning it into three small programs still creates more work than the arithmetic suggests.

My first pricing model could express those programs. It knew about package scope, conditions, calculated amounts, and ordered adjustments. The problem wasn’t an inability to calculate the right price. It was that ordinary tariff structure kept arriving as another expression for the system to interpret. That affected editing, validation, and eventually execution.

Eager Loading Is Not a Query Shape

Sat, 01 Feb 2025 00:00:00 +0000

A catalogue endpoint returns 25 names and the number of active variants behind each one. The first implementation runs 26 queries. Adding with('activeVariants') reduces that to two.

The N+1 defect is gone. The new implementation still hydrates 1,250 Variant models, including a synthetic 4 KiB metadata column, to produce 25 integers.

Eager loading solved the repeated-query shape. It did not ask what the response needed. That is the larger decision: queries, selected rows and columns, hydrated models, serialization, and the database plan all belong to one read path.

CQRS Starts When Reads Need a Different Model

Mon, 01 May 2023 00:00:00 +0000

An order-details page needs customer name, payment status, shipment progress, line totals, tax labels, and the latest support case. The write model needs to protect payment, cancellation, and fulfilment invariants.

Trying to make one Eloquent graph serve both jobs creates a familiar mess: relationships exist for screen composition, write methods expose persistence concerns, and every request loads a different subset of a model that is never quite complete.

This is where CQRS becomes a real option. It still does not automatically justify two databases, an event store, a command bus, or eventual consistency. CQRS is the model split; the infrastructure is a separate set of decisions.

A Version Column Is Not Concurrency Control

Sun, 01 Jan 2023 00:00:00 +0000

A capacity pool has ten units available. Two workers load it before either one writes:

worker A loads: version 0, reserved 0
worker B loads: version 0, reserved 0

worker A allocates 6 to allocation-a
worker B allocates 6 to allocation-b

Both decisions pass the aggregate’s rule. Each worker sees ten remaining units. They cannot both belong to one ordered history: after either allocation, only four remain.

Construction Should Not Hide Durable Writes

Tue, 01 Sep 2020 00:00:00 +0000

A test called a model factory’s make() method. The model itself was never saved. Two related records were.

The factory computed the model’s default address and account fields by creating real database rows. A test which only needed an in-memory user therefore changed shared state before it reached its first assertion.

A surrounding test transaction usually hid the damage by rolling it back. Tests without that transaction left the rows behind, while another test used TRUNCATE for cleanup, committed the MySQL transaction, and made earlier writes survive the rollback. The method returned an unpersisted object, but its name still gave the wrong account of what had happened.

An Index Must Serve a Real Query

Sun, 01 Oct 2017 00:00:00 +0000

A production query needed a small page of recent records requiring operational attention. The table already had an index which looked relevant. The measured scan still discarded 84,003 historical index entries and recorded 122,936 shared-buffer reads before finding 83 eligible rows.

The table did not need another vaguely relevant index. It needed an index for this query:

one tenant
active records with zero price
created during the last three months
newest creation time first
stable identifier as the tie-breaker
first page only

That is the actual starting point: the access path, not a list of columns which sound important in isolation.

Pagination Needs a Stable Order

Fri, 01 Sep 2017 00:00:00 +0000

A financial report encoded two sort rules as one string:

lowercased customer name + "-" + customer identifier

Sharded tests with concurrently created identifiers exposed unreliable output. The correction stopped asking string concatenation to double as a sorting contract. It compared names directly and consulted the stable customer identifier only when the names matched.

The diff does not prove that equal names alone caused the failing order. It does expose the rule every paginator depends on: the primary comparison, tie-breaker, and comparison semantics must be explicit, and each row needs exactly one reproducible position.

Time Zones Are Part of the Data Model

Thu, 01 Jun 2017 00:00:00 +0000

One metering path assigns an event to a billing month after converting its occurrence time into the account’s timezone. The same path derives its daily usage key directly from the occurrence timestamp without that conversion.

Near midnight, those two fields can disagree:

event instant: May 31, 21:30 UTC
local business time: June 1, 00:30
billing period: June
stored usage date: May 31

Each expression looks like an ordinary date calculation. They model different things, and the defect stays invisible until the difference crosses a day or month boundary.

Money Is Not a Floating-Point Number

Mon, 01 May 2017 00:00:00 +0000

A booking-time price arrived as four values:

net amount: 407
tax rate: 25.5%
tax amount: 104
gross amount: 511

The amounts are integers in the currency’s minor unit. The rate is a decimal ratio. The contract checks two things: net plus tax equals gross, and the declared rounding rule produces the supplied tax amount from net and rate.

None of those details is bookkeeping trivia. Remove the unit, mix the rate’s two representations, or let two services round at different stages, and the same price can stop balancing while every individual calculation still looks reasonable.

Null Is a Domain Decision

Sat, 01 Apr 2017 00:00:00 +0000

We added four nullable fields to preserve a pricing snapshot: net amount, tax rate, tax amount, and gross amount. Each field could now be absent. That did not make each field independently optional.

For older records, all four nulls meant one thing: this record predates the snapshot and does not contain captured pricing evidence. For new records, all four values had to arrive together. A row containing gross and net but no tax rate was not “partly known.” It was invalid.

A Migration Is a Production Change

Wed, 01 Mar 2017 00:00:00 +0000

We deployed an additive schema change which the database could execute without rewriting the table. On paper it was cheap. In production it waited indefinitely.

The statement needed an exclusive table lock. A long-running session already held a conflicting lock, so the migration queued. New application traffic then queued behind the migration. The column addition was cheap after lock acquisition; waiting to begin was the incident.

Another schema change looked cheap for the opposite reason: remove fields and tables which the application no longer read. The SQL was small, but the decision would erase financial history from data sets measured in tens of gigabytes. Neither change could be judged by reading the migration method alone.

A Transaction Defines What Must Succeed Together

Wed, 01 Feb 2017 00:00:00 +0000

A booking flow reserved funds, completed the remote booking, and captured the funds. Only then did synchronous response processing fail. The remote booking existed, the funds were captured, and the caller received a failure.

The capture was individually valid, and its own database transaction committed cleanly. It was still too early. We had drawn the success boundary around “remote booking returned” while the operation promised something larger: a complete booking result which the caller could use.

Let the Database Reject Impossible State

Sun, 01 Jan 2017 00:00:00 +0000

Two workers asked the same reasonable question: does this owner already have an active record? Both received the same honest answer: no. Each worker then created one.

Nothing in either request was obviously careless. The application checked first. The insert happened inside a transaction. Tests which ran one request at a time stayed green. The defect lived in the interval between the check and the write, where both transactions were allowed to be correct about a state which had already become stale.

A Release Gate Must Fail Before Incompatible Code Goes Live

Tue, 01 Nov 2016 00:00:00 +0000

We had a deployment step everybody knew about and people still forgot it. The code was pulled manually, then someone had to run a shell script which applied pending migrations. The instructions existed, but the habit remained concentrated in one operator.

Eventually a deployment completed without the script. Traffic reached code which expected columns or tables that did not exist, and database queries began failing. Running the migrations restored the application. There was no obscure database bug here; the release process had declared success before one of its prerequisites was true.

Production Bugs Can Live in the Data, Not the Code

Mon, 01 Feb 2016 00:00:00 +0000

A delivery integration returned a label, but the application could not save it. The same persistence path had passed with the fixtures used elsewhere.

The failed label was not malformed. It was simply larger than the database column could hold after Base64 encoding.

That distinction changes the investigation. Comparing deployed revisions would find nothing because the revision was not the variable. Repeating a familiar fixture would also find nothing because the fixture did not cross the same storage boundary. The investigation had treated “same code” as “same experiment” while leaving the input that decided the result uncontrolled.