Skip to main content

Why not direct access

Five costs, each one a thing that has already happened somewhere

Direct access is not wrong because it is old-fashioned. It is wrong because of five specific consequences, and each is easier to recognise as a scenario than as a principle.

01 · The schema is the de-facto public API​

A column named status holds four values. A fifth is needed. The owning team greps its own code, changes it, and ships — and a reporting job in another department that has WHERE status IN (...) hard-coded silently stops counting a fifth of the orders. Nobody notices for a month.

The lesson teams draw is not "coordinate better". It is "never change that column". After a few rounds of this, the schema is frozen by fear, and the fastest way to add a field is to overload an existing one.

02 · Authorization is table-shaped, and the audit trail names a connection​

A grant says SELECT on orders. It cannot say which rows, for what, or on whose behalf. When the audit question arrives — who read this customer's orders on the 14th — the answer available is a connection from an application server, shared by every request that application served that day.

This is the gap a contract closes: the owning service knows the caller, the operation and the row, and can record all three. How the owner comes to know the caller — a service identity it verifies on every request — is on the contract page, under Caller identity.

03 · The coupling is invisible​

Before touching a table, the honest question is "who reads this?". With direct access there is no answer — only a list of credentials that have the grant, which is a list of who could, not who does. Planning a change means asking around and hoping the person who knows is not on leave.

This is why ownership starts with an inventory taken from the database side rather than from a survey: the estate is what it is regardless of what teams remember.

04 · Connections scale with instances​

Each application replica opens its own connection pool. Ten replicas of six applications is sixty pools, sized for peak, mostly idle, and all of them counted against one max_connections.

Today the replica count is fixed because the applications are on hand-built VMs. Roadmap item 26 moves them onto Kubernetes, where the whole point is that replica count moves with load — and the database is the thing that cannot absorb that.

05 · It blocks the platform underneath​

Two items on the roadmap are waiting on this:

  • Item 06 — Database IaC & DBaaS. Changing a replication topology or a failover target means knowing every client. Unknown readers make it a change nobody will sign off.
  • Item 27 — Multi-site warehouse. A site can only be independent if what reads its data is known and local. An undocumented cross-site reader turns a site outage into a company outage.

Neither is solved by adding APIs. Both are solved by the reader set becoming knowable, which is the same prerequisite.