Eduardo's blog

Why care about programming languages

2026-07-22T00:00:00Z

In the age of AI-assisted coding, it’s easy to feel that deep knowledge of programming languages has become obsolete. Why spend years mastering language intricacies when an AI can generate code in any language on demand? I recently encountered this sentiment in a question from a fellow developer:

I feel like caring about programming languages and stuff is actually very useless. … Am I being too extreme?

I understand the concern, but I believe it misses something fundamental: a programming language’s worth is derived from the ideas it embodies, not merely its syntax or tooling. These ideas—concepts about how to structure thought, manage complexity, and solve problems—remain essential regardless of who or what writes the code.

Here is my sample list of deep ideas from programming languages:

on Rust, the borrow checker—reasoning about ownership and lifetimes
on Haskell, typeclasses—principled polymorphism and abstraction
on SML/OCaml, the module system—large-scale program organization and decoupling
on OOP languages, identity vs equality—understanding state and comparison
on SQL, relational theory/algebra—declarative data manipulation
on Prolog, first order predicate logic—logic-based problem solving
on C, arrays and pointers—understanding memory layout and indirection
on Lisp, syntax extensions—metaprogramming and language-oriented programming
on functional languages, first class functions—treating computation as values
on SML, Haskell and others, algebraic data types—modeling domains with types
on Clojure, maps and immutable data structures—persistent data and structural sharing
on OCaml, row polymorphism—static typing for extensible records

Each of these concepts represents a different way of thinking about computation. Learning them expands your mental toolkit for solving problems. When you understand the borrow checker, you think differently about resource management everywhere. When you grasp algebraic data types, you model domains more precisely. When you internalize first-class functions, you see abstraction opportunities others miss.

These ideas transcend any particular language or tool. They are the conceptual foundation that lets you evaluate AI-generated code, choose appropriate abstractions, and architect systems that remain maintainable as they grow. In the AI age, understanding these concepts becomes more important, not less—they are what separate those who merely prompt from those who truly engineer.

Figure 1: A man praying in a ruined Catholic church in La Vang, a town south of Quang Tri City, Vietnam on July 6, 1972

On keys, essences and performance

2026-07-14T00:00:00Z

A recent exchange on linkedin about what data is and how to store it prompted me to write this small piece, since I consider the issue at hand quite fundamental to developing systems that reflect reality and therefore help people.

Here is what the author of the quote said:

I mean that actual data, as observed in the world around us - may not have natural keys as required by the model. Nor are data domains clearly definable. We can’t even agree what a country is - nor figure out how to properly track human languages or lock down standards for how the semantics of programming language are supposed to work. And what key can we even use to uniquely identify an individual - when legislation often forbids the storage of any keys? Normalisation is also a very poor way to organise data that needs to be analysed at speed (which is why almost no analytical systems use normalised models)

I’ll break down the argument into its propositions and my answer to each is below.

data as observed may not have natural keys as required by the (relational) model (RM)

I would define a key in the RM as a part of the proposition denoted that allows for it to be uniquely referred to in the given Domain of Discourse.

If one accepts that definition, how can something denoted not have a key? If one is denoting it, one needs to refer to it somehow unambiguously. Any system that deals with the data would do that, be it in the application layer or the DBMS layer.
data domains are not clearly definable

This is the same issue as above, but on the predicate level instead of the proposition level. If we can refer to a proposition (e.g. Bob’s salary is 100) we can certainly refer to its predicate (E’s salary is X). And if we can’t, we cannot process it in any given system.
legislation would disallow keys

Then such legislation would force the predicate to change (maybe to aggregates only?). In other words, the legislation constrains the Domain of Discourse, but all the properties of such remain.
normalization makes systems performs badly

Normalization means that a given encoded relation refers to a single logical predicate. That bears no significance, at least in principle, to performance.

Conclusion

The necessity of keys and normalization is not a quirk of the relational model. It reflects something deeper about the world we are modeling (our Universe of Discourse). We must refer to things unambiguously, and for that things must possess stable, distinguishing essences.

The difficulty of identifying what a country is, or what constitutes an individual, is not evidence that essences do not exist. It is evidence that discovering them is hard. That is an epistemological challenge, not an ontological absence.

The relational model, far from imposing an artificial structure on formless data, simply makes explicit what any coherent discourse about reality already presupposes: that the world is composed of things with essences, and that we can know them

Figure 1: Defacement of the church of Saint-Martin by the French revolutionaries

All you need is PostgreSQL

2026-06-25T00:00:00Z

Introduction

There is a deep cultural reflex in modern engineering: whenever a problem appears, reach for a packaged solution instead of thinking from first principles. The result is architectural cargo culting and lots of missed opportunities. Some intentionally absurd-but-familiar examples:

We need an audit trail, let’s use {temporal/event sourcing DBMS}

Our application is slow, let’s cache that using {in-memory key-value database}

And since a relational database like PostgreSQL is still considered mandatory,thanks mostly to its unmatched reputation, companies end up stacking product on top of product on top of PostgreSQL. They inflate the number of moving parts, operational risk, headcount demand, and overall system entropy. Complexity¹ grows, not because the problems demand it, but because someone reached for a tool they saw in a conference talk.

In this post, I’ll walk through a set of common misconceptions that drive teams to introduce new infrastructure when they don’t need to. All of these can be solved with vanilla PostgreSQL 18 using standard extensions available on RDS, with no special infrastructure and no distributed-systems cosplay.

The goal in this article is not to argue that specialized systems are never appropriate, but to show that the default assumption for your data problems should be that my company can do fine with just PostgreSQL.

The setup

Here is a list of arguments that people put forth to reach for other tools besides PostgreSQL, based on my experience:

I’ll need auditing and reconstructing state
Write throughput is too low
The transactional queries are too slow
The analytical queries are too slow
My app will be coupled to the Database

To address these, I’m going to use a variation of the Drosophila melanogaster of the database field: the classic Supplier and Parts database(Date 2003). I’ll update it to be more in line with the usual problematic tables: Financial Transaction and their originating transfers.

For the rest of this article we will be constructing a database design based on modern PostgreSQL that will achieve the general goals listed above and specific business requirements. Here is a requirements snippet from a very popular banking API company:

Transactions: are immutable records of financial interactions with Increase. You can think of them as the line items on your bank statement. A Transaction with a positive amount means there’s more money in your account. A Transaction with a negative amount means there’s less money in your account. You can’t directly create a Transaction, and they never change after they are made. Anything that causes money to move around your Increase account results in a Transaction - initiated or received transfers, card payments, earned interest, and more.

Transfers: which includes ACH Transfers, Wire Transfers, etc - are the most common way to initiate money movement over external networks with Increase. Transfers are one-to-many with Transactions, which they create as side-effects. Unlike Transactions, Transfers are stateful and transition through a lifecycle of different statuses as they move across the network.

Pending Transactions: represent potential future credits or debits of money into your account and are a separate resource from Transactions (despite their similar name). Notably, while Transactions are immutable, Pending Transactions are not, as they don’t guarantee the movement of money. For example, Pending Transactions are created for card authorizations (which can mutate or timeout) and also when placing a hold on an account (which can be removed). Pending Transactions do not affect your current balance (which is the balance you earn interest on), but do affect your available balance (which is the amount you’re able to move out of Increase). (Increase, Inc. 2025)

Below are 2 screenshots from increase’s sandbox dashboard that showcase the requirements:

Figure 1: Increase account dashboard

Figure 2: Increase details

From these 2 images, here is a list of requirements (functional and not) that I have extracted, which I consider to be common in financial systems like increase:

Accounts are defined by immutable routing numbers and account numbers and have a status that can vary.
Accounts are discriminated between external and managed, and one account must be one or the other exclusively. Transfers are made only between external and managed accounts.
Transactions and transfers are listed, paginated by their respective creation times.
Current and available balance are shown, both their present and historical daily values
Transfers behave like a state machine where the progression between states are exposed to the user. The user can see the full state history of a transfer and some of these states are linked to pending/settled transactions.
The user can also see the details of a transaction, and see the transfer that generated it.
We should maximize write throughput of transactions and transfers. Transfers are editable, and so we should be able to update them fast too.

Laying the foundation

In this section we build the core tables² and the role necessary to restraint updates and achieve the immutability mentioned on the requirements (requirement 1 for example).

The foundation: schemas and user roles for modularity

Modularity, defined by the capacity to have a many-to-many relation between implementations and interfaces(Koppel 2023), is crucial for software development(Yourdon and Constantine 1979). Part of the base tools we have for that on SQL are schemas and roles. In particular, a proper role³ can be used for defining very precise interfaces on top of database objects(Swart 2019).

create schema finance;

create role finance;
grant usage on schema finance to finance;
alter default privileges in schema finance
  grant select, insert, update, delete on tables to finance;

alter default privileges in schema finance
  grant usage, select on sequences to finance;

Domains

Database domains are usually scoffed at by practitioners, but that is a big mistake. Properly seen, they are

an application of the abstract data type to database management. (Pascal 2019)

As such, domains are the core building blocks for logical design.

create domain finance.routing_number as text
check (value ~ '^[0-9]{9}$');

create domain finance.account_number as text
  check (value ~ '^[0-9]{12}$');

create domain finance.transfer_status as text
  check(value in ('pending',
                  'returned',
                  'completed'));

The transfer_status in particular is crucial, since it represents the valid states that a state machine can have.

Accounts, managed and external

Managed Accounts are the accounts that are owned by the our system. When receiving a transfer, we control only one side of the transfer, and that is the managed account side.

Managed accounts can be deactivated and reactivated. This falls neatly within the set of temporal features introduced in SQL 2011(Kulkarni and Michels 2012), in particular application time, recently introduced in PostgreSQL 18(PostgreSQL Wiki Contributors 2024). This feature allows us to represent accounts going in and out of activity without overlapping.⁴

-- To use temporal constraints, you need to install the btree_gist extension, which provides the necessary operator classes for creating GiST indexes on scalar data types:
create extension if not exists btree_gist;

create table finance.managed_active_account(
  routing_number  finance.routing_number not null,
  account_number  finance.account_number not null,
  account_name    text not null,
  account_active_period tstzrange not null default tstzrange(now(), 'infinity', '[)'),
  primary key (routing_number,
               account_number,
               account_active_period without overlaps)
);

comment on table finance.managed_active_account is
  'Managed Accounts are what transactions are performed against. Think of your bank account. They store money, receive transfers, and send payments. They earn interest and have depository insurance. This relation holds the accounts that are active. No transfer may be created for accounts in the period that they were inactive.';

create table finance.external_account(
  routing_number  finance.routing_number not null,
  account_number  finance.account_number not null,
  account_name    text not null,
  primary key (routing_number, account_number)
);

comment on table finance.external_account is
  'External accounts represent counterparty accounts at other institutions. They are the other side of a transfer. Unlike managed accounts, they have no temporal active period since we do not control their lifecycle.';

And below we finish the accounts by making sure a managed account and an external account can’t be the same. We need to use alter table instead of adding these check constraints on the table definitions because of the circular dependency (one table depends on the other, and vice versa).

-- Ensure managed and external accounts never share the same identity
create or replace function finance.not_external_account(
  p_routing_number finance.routing_number,
  p_account_number finance.account_number
)
  returns boolean language sql stable as $$
  select not exists (
    select 1
      from finance.external_account
     where routing_number = p_routing_number
       and account_number = p_account_number
  );
$$;

create or replace function finance.not_managed_account(
  p_routing_number finance.routing_number,
  p_account_number finance.account_number
)
  returns boolean language sql stable as $$
  select not exists (
    select 1
      from finance.managed_active_account
     where routing_number = p_routing_number
       and account_number = p_account_number
  );
$$;

alter table finance.managed_active_account
  add constraint managed_not_external
  check (finance.not_external_account(routing_number, account_number));

alter table finance.external_account
  add constraint external_not_managed
check (finance.not_managed_account(routing_number, account_number));

Transfers, constrained by a state machine and temporal periods

Below are the transfers, which represents the movement of money between managed accounts and external accounts. They can be seen as a state machine progressing over the transfer_status domain pending -> (completed | returned).

Another crucial point here is the period keyword in the references section. This makes a transfer period be consistent with active managed accounts, implementing a core financial safety requirement declaratively in the most deepest level one can.

create table finance.transfer (
  transfer_period             tstzrange not null default tstzrange(now(), 'infinity', '[)'),
  transfer_created_at         timestamptz
                              generated always as (lower(transfer_period)) stored,
  account_number              finance.account_number not null,
  routing_number              finance.routing_number not null,
  counterparty_account_number finance.account_number not null,
  counterparty_routing_number finance.routing_number not null,
  amount                      bigint not null,
  status                      finance.transfer_status not null default 'pending',
  -- Natural order: account identity, then time, then counterparty
  -- This enables efficient time-range queries on account transfers
  primary key (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number
  ),
  foreign key (
    counterparty_routing_number,
    counterparty_account_number
  ) references finance.external_account (
    routing_number,
    account_number
  ),
  -- temporal foreign key: ensure managed account exists during transfer period
  foreign key (
    routing_number,
    account_number,
    period transfer_period
  ) references finance.managed_active_account (
    routing_number,
    account_number,
    period account_active_period
  )
);

comment on table finance.transfer is
  'Transfers represent money movement between an external account and a managed account. Status follows state machine: pending -> (completed | returned). Period closes on terminal state. transfer_created_at is a stored generated column derived from lower(transfer_period), eliminating redundancy while remaining usable in primary keys and foreign key references.';

revoke insert on finance.transfer from finance;
revoke update on finance.transfer from finance;
-- transfer_period will be managed based on the status
grant insert (routing_number,
              account_number,
              counterparty_routing_number,
              counterparty_account_number,
              amount) on finance.transfer to finance;
grant update (status) on finance.transfer to finance;

Note that transfer_created_at is a stored generated column: lower(transfer_period) is an immutable function, and the lower bound of transfer_period never changes (the state machine trigger only closes the upper bound). This eliminates the redundancy between transfer_created_at and lower(transfer_period) while keeping the column usable in primary keys and as a foreign key target.

Transfer state history

In order to implement feature 5, we need system-time temporal tables⁵. PostgreSQL supports several approaches for temporal tables. For simplicity and portability (including RDS), we use the temporal_tables extension (https://nearform.com, n.d.).

The extension automatically writes old versions of each row to a history table on every UPDATE or DELETE. Together with a tstzrange period, this gives you a full history suitable for AS OF queries and state reconstruction. We create a focused history table that only tracks what we need: the transfer identity, status, and system-time period.

-- Add system-time period column to transfer table
alter table finance.transfer add column if not exists sys_period tstzrange default tstzrange(current_timestamp, null);
alter table finance.transfer alter column sys_period set not null;

-- Focused history table - only what we need for status transitions
create table if not exists finance.transfer_status_log (
  like finance.transfer
);

comment on table finance.transfer_status_log is
  'Automatic log of all transfer status transitions via temporal_tables extension. Shows complete state machine history.';

alter table finance.transfer_status_log
  add primary key (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number,
    sys_period
  );

-- Use temporal_tables versioning procedure
create trigger transfer_save_status_history
  before insert or update or delete
  on finance.transfer
  for each row
  execute procedure versioning('sys_period', 'finance.transfer_status_log', true);

Once applied, finance.transfer_status_log will contain every past version of every transfer’s status, from which you can reconstruct the state machine history over time.⁶

Account auditing

Since we are on the subject of temporal tables, we might as well add support for auditing accounts. It lies outside our list of features, but I think account disabling is a major event that should have strong auditing behind it, so we might as well add it.

-- Add system-time period column to the account table
alter table finance.managed_active_account add column if not exists sys_period tstzrange default tstzrange(current_timestamp, null);
alter table finance.managed_active_account alter column sys_period set not null;

create table if not exists finance.managed_active_account_log (
  like finance.managed_active_account
);

comment on table finance.managed_active_account_log is
  'Automatic log of all account activity via temporal_tables extension.';

create index on finance.managed_active_account_log (sys_period);
create index on finance.managed_active_account_log (routing_number, account_number);

-- Use temporal_tables versioning procedure
create trigger account_save_history
  before insert or update or delete
  on finance.managed_active_account
  for each row
  execute procedure versioning('sys_period', 'finance.managed_active_account_log', true);

Transactions, the immutable events

Contrasted with the above, below we have transactions, which represent changes in the balances (current and available) of an account and are therefore immutable.

Transactions reference their originating transfer by identity (the transfer’s natural key including transfer_created_at), not by period. There is no transfer_period stored on transactions — the transfer’s temporal state is queried from the transfer table when needed.

create table finance.settled_transaction (
  transaction_created_at      timestamptz not null default now(),
  account_number              finance.account_number not null,
  routing_number              finance.routing_number not null,
  counterparty_account_number finance.account_number not null,
  counterparty_routing_number finance.routing_number not null,
  transfer_created_at         timestamptz not null,
  amount                      bigint not null,
  primary key (
    account_number,
    routing_number,
    transaction_created_at
  ),
  foreign key (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number
  )
  references finance.transfer (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number
  )
);

comment on table finance.settled_transaction is
  'Settled transactions affect both your available balance and your current balance. They are immutable events --- no updates or deletes permitted.';

revoke update, delete on finance.settled_transaction from finance;

create table finance.pending_transaction (
  like finance.settled_transaction including all,
  foreign key (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number
  )
  references finance.transfer (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number
  )
);

comment on table finance.pending_transaction is
  'Pending transactions represent potential future credits or debits. They affect available balance but not current balance. Immutable once created.';

revoke update, delete on finance.pending_transaction from finance;

On maintaining business rules via meaningful constraints

Constraints should really be part of the foundation, but I have made them a separate section because they are usually seen as something apart from defining tables. In reality, a proper mathematical relation should embrace both intentionality (constraints) and extensionality (rows).

It is impossible to design and interrogate a database sensibly, and ensure semantic consistency of results … it is intended to represent without … DBMS knowledge of the meaning assigned to the database…(Pascal 2026)

In our case, several business rules must hold across tables. In the absence of SQL’s assert⁷ we rely on constraint triggers keeping them as declarative as possible.

The transfer state machine

create or replace function finance.enforce_transfer_state_machine()
  returns trigger language plpgsql as $$
begin
  if OLD.status = NEW.status then
    return NEW;
  end if;

  if OLD.status = 'pending' then
    if NEW.status not in ('completed', 'returned') then
      raise exception 'Invalid state transition: pending can only transition to completed or returned, not %', NEW.status;
    end if;
    NEW.transfer_period := tstzrange(lower(OLD.transfer_period), now(), '[]');

  elsif OLD.status in ('completed', 'returned') then
    raise exception 'Invalid state transition: % is a terminal state and cannot transition to %', OLD.status, NEW.status;
  end if;

  return NEW;
end;
$$;

create trigger transfer_z_enforce_state_machine
  before update of status on finance.transfer
  for each row
  when (OLD.status <> NEW.status)
  execute function finance.enforce_transfer_state_machine();

Transactions must fall within the transfer period

A transaction’s transaction_created_at must fall within the originating transfer’s transfer_period. This prevents creating transactions against transfers that haven’t started yet or have already closed:

create or replace function finance.transaction_within_transfer_period()
  returns trigger language plpgsql as $$
declare
  v_transfer_period tstzrange;
begin
  select transfer_period into v_transfer_period
    from finance.transfer
   where routing_number              = NEW.routing_number
     and account_number              = NEW.account_number
     and transfer_created_at         = NEW.transfer_created_at
     and counterparty_routing_number = NEW.counterparty_routing_number
     and counterparty_account_number = NEW.counterparty_account_number;

  if not found then
    raise exception 'Transfer not found for transaction';
  end if;

  if not (v_transfer_period @> NEW.transaction_created_at) then
    raise exception
      'Transaction created_at % is outside transfer period %',
      NEW.transaction_created_at, v_transfer_period;
  end if;

  return NEW;
end;
$$;

create constraint trigger settled_transaction_within_transfer_period
  after insert on finance.settled_transaction
  deferrable initially deferred
  for each row
  execute function finance.transaction_within_transfer_period();

create constraint trigger pending_transaction_within_transfer_period
  after insert on finance.pending_transaction
  deferrable initially deferred
  for each row
  execute function finance.transaction_within_transfer_period();

Pending transactions require a pending transfer

A pending transaction can only be created against a transfer that is still in the pending state. Settled transactions, conversely, can only be created against transfers that have left the pending state (i.e. completed or returned):

create or replace function finance.is_pending_transfer(
  p_routing_number finance.routing_number,
  p_account_number finance.account_number,
  p_transfer_created_at timestamptz,
  p_counterparty_routing_number finance.routing_number,
  p_counterparty_account_number finance.account_number
)
  returns boolean language sql stable as $$
  select exists (
    select 1
      from finance.transfer t
     where t.routing_number              = p_routing_number
       and t.account_number              = p_account_number
       and t.transfer_created_at         = p_transfer_created_at
       and t.counterparty_routing_number = p_counterparty_routing_number
       and t.counterparty_account_number = p_counterparty_account_number
       and t.status                      = 'pending'
  );
$$;

create or replace function finance.ensure_pending_transfer()
  returns trigger language plpgsql as $$
begin
  if not finance.is_pending_transfer(
    NEW.routing_number,
    NEW.account_number,
    NEW.transfer_created_at,
    NEW.counterparty_routing_number,
    NEW.counterparty_account_number
  ) then
    raise exception
      'Must reference a pending transfer (%, %, %, %, %)',
      NEW.routing_number, NEW.account_number, NEW.transfer_created_at,
      NEW.counterparty_routing_number, NEW.counterparty_account_number;
  end if;
  return NEW;
end;
$$;

create or replace function finance.ensure_non_pending_transfer()
  returns trigger language plpgsql as $$
begin
  if finance.is_pending_transfer(
    NEW.routing_number,
    NEW.account_number,
    NEW.transfer_created_at,
    NEW.counterparty_routing_number,
    NEW.counterparty_account_number
  ) then
    raise exception
      'Cannot reference a pending transfer (%, %, %, %, %)',
      NEW.routing_number, NEW.account_number, NEW.transfer_created_at,
      NEW.counterparty_routing_number, NEW.counterparty_account_number;
  end if;
  return NEW;
end;
$$;

create constraint trigger pending_transaction_requires_pending_transfer
  after insert on finance.pending_transaction
  deferrable initially deferred
  for each row
  execute function finance.ensure_pending_transfer();

create constraint trigger settled_transaction_requires_non_pending_transfer
  after insert on finance.settled_transaction
  deferrable initially deferred
  for each row
  execute function finance.ensure_non_pending_transfer();

No future transactions when closing a transfer

A transfer cannot transition to completed or returned if any of its transactions have a transaction_created_at that falls after the moment of closure. This prevents the state machine from closing a transfer’s period and stranding transactions in the future:

create or replace function finance.no_future_transactions_on_close()
  returns trigger language plpgsql as $$
begin
  if exists (
    select 1 from finance.settled_transaction
     where routing_number              = NEW.routing_number
       and account_number              = NEW.account_number
       and transfer_created_at         = NEW.transfer_created_at
       and counterparty_routing_number = NEW.counterparty_routing_number
       and counterparty_account_number = NEW.counterparty_account_number
       and transaction_created_at > now()
    union all
    select 1 from finance.pending_transaction
     where routing_number              = NEW.routing_number
       and account_number              = NEW.account_number
       and transfer_created_at         = NEW.transfer_created_at
       and counterparty_routing_number = NEW.counterparty_routing_number
       and counterparty_account_number = NEW.counterparty_account_number
       and transaction_created_at > now()
  ) then
    raise exception
      'Cannot close transfer (%, %, %): transaction(s) exist after current time',
      NEW.routing_number, NEW.account_number, NEW.transfer_created_at;
  end if;

  return NEW;
end;
$$;

create constraint trigger transfer_no_future_transactions_on_close
  after update of status on finance.transfer
  deferrable initially deferred
  for each row
  when (NEW.status in ('completed', 'returned'))
  execute function finance.no_future_transactions_on_close();

These three constraint groups — temporal containment, status matching, and future-transaction prevention — together enforce the full lifecycle invariant: transactions can only exist within the temporal and logical boundaries of their originating transfer. In application code, this would typically require a coordination framework spanning multiple services. Here it is enforced declaratively at the deepest possible level.

On capacity planning

In order to be able to efficiently modify transfers and run the constraints needed to keep transactions consistent with the business rules we should keep in the working set 2 days of transfers/transactions. The number 2 is chosen because wire transfers typically settle within one business day and while international transfers take one to five days, with most completing within two(Paystand 2024) we.

Taking finance.transfer as a reference (the widest row), we estimate the per-row size (ignoring alignment(Thomas 2018)):

Name	Type	Size (bytes)
transfer_period	tstzrange	32
transfer_created_at	timestamptz	8
account_number	text(12)	13
routing_number	text(9)	10
counterparty_account_number	text(12)	13
counterparty_routing_number	text(9)	10
amount	bigint	8
status	text(10)	11
sys_period	tstzrange	32
Total (plus 24 row header)		161

So roughly 160 bytes per row. The log tables have the same width. The transaction tables are slightly narrower (no transfer_period, no status), around 120 bytes per row.

Working set estimation

The working set is the data that must be in shared_buffers for the system to perform well. As stated above, the working set will consist of 2 days of transfers transactions.

Let’s assume that a transfer row corresponds to 2 rows in transfer_status_log (the initial insert plus a state change) and 3 transactions (2 pending transactions and a settled transaction). That gives us 3 transfer like rows + 3 transaction rows.

Each index entry carries 8 bytes of overhead plus the indexed data[cite:@StackOverflowAlbe2020indexsize]. In our design, most tables have one index: the B-tree backing the primary key (the temporal table has 2, but lets ignore that for the sake of simplicity). The primary key for ~finance.transfer indexes 5 columns totalling ~54 bytes, so each index entry is ~62 bytes. This amounts to roughly 40% of the row size. So, a safe rule of thumb: add a 1.4 multiplier to the table sizes to account for for index overhead.

This whole argument boils down to the byte sum of:

((3 * 160) + (3 * 120)) * 1.4

1176.

Scale	Transfers/day	Working set size for 2 days
Startup	10,000	22M
Mid/large bank(Nubank 2022)	50,000,000	110G
Global processor(Inc. 2025)	900,000,000	1.9T

Up to a mid level bank one can fit the working set comfortably in modern cloud database servers. AWS RDS, for instance, supports up to 4TiB of memory per instance for PostgreSQL-compatible instances(Amazon Web Services 2026).

On write throughput

If you want to maintain semantic enforcement of your data (which in our model is done via fkeys and constraint triggers) about the best thing you can do to optimize write throughput is to lower the write amplification, specifically to use indexes in a smart way. After all, indexes, if not carefully chosen, can kill performance in a write-heavy application(Gerogiannakis 2019)

Enabling HOT Updates for Transfers

By keeping the primary key of the finance.transfer table aligned with the immutable columns, we enable Heap-Only Tuple (HOT)(The PostgreSQL Global Development Group 2025) updates for that table. Such HOT updates are important because status transitions (pending to completed/returned) are common operations and we want to minimize write amplification.

What happens is that, because neither the transfer’s status nor its transfer_period participate in any indexes, PostgreSQL can write the new tuple version to the same page (if space permits) and also skip the index update entirely.

We therefore need to make sure there is enough page space in the table:

alter table finance.transfer set (fillfactor = 70);

This reserves 30% free space per page, allowing updated tuples to fit on the same page. Combined with no indexes on status or transfer_period, status updates become HOT-eligible, providing:

2-3x faster updates compared to non-HOT updates(Samuel 2024)
No table and index bloat from status changes(van Veen & Dave Pitts 2022)
Simpler vacuum maintenance on the table(van Veen & Dave Pitts 2022)
Smaller WAL, since there is less write activity overall(van Veen & Dave Pitts 2022)

Making sure there are no Unused indexes

A common problem is to have a bunch of unused indexes for critical tables, since they are not visible directly and experiments can be forgotten. So, make sure all indexes are being used (see (Gerogiannakis 2019)(Group, n.d.) for a solution based on PostgreSQL internal statistics):

SELECT schemaname, relname, indexrelname, idx_scan, idx_tup_read, idx_tup_fetch FROM pg_stat_user_indexes where schemaname='finance' ORDER BY idx_scan;

 schemaname │         relname          │              indexrelname               │ idx_scan │ idx_tup_read │ idx_tup_fetch
════════════╪══════════════════════════╪═════════════════════════════════════════╪══════════╪══════════════╪═══════════════
 finance    │ settled_transaction      │ settled_transaction_pkey                │        0 │            0 │             0
 finance    │ transfer_status_log      │ transfer_status_log_sys_period_idx      │        0 │            0 │             0
 finance    │ account                  │ account_pkey                            │      100 │           80 │            60
 finance    │ pending_transaction      │ pending_transaction_pkey                │  1220000 │       120000 │        120000
 finance    │ transfer                 │ transfer_pkey                           │  2210002 │      1110002 │       1110000

idx_scan

How many times the index has been scanned (used). This can be either directly by a application query e.g.

select * from finance.transfer where
(transfer_created_at, transaction_account, counterparty_account) =
('2025-11-25 18:04:26.298329+00'::timestamptz, 'acc_8', 'acc_15');

or indirectly due to a JOIN. For example, the primary key index transfer_pkey has been scanned over 2210002 times.

idx_tup_read

This is the number of index entries returned as a result of an index scan. An easy-to-understand example is the primary key (e.g.

select * from finance.transfer where (transfer_created_at, transaction_account, counterparty_account) = ('2025-11-25 18:04:26.298329+00'::timestamptz, 'acc_8', 'acc_15');

). If there is such transfer, then idx_tup_read will increase by 1. Modifying slightly the query

select * from finance.transfer
 where (transfer_created_at, transaction_account, counterparty_account) in
       (('2025-11-25 18:04:26.298329+00'::timestamptz, 'acc_8', 'acc_15'),
       ('2025-11-25 01:39:36.594342+00'::timestamptz, 'acc_11', 'acc_9'));

idx_tup_read will increase by 2 (if both transfers exist). In both of these queries, idx_scan will increase by 1.

idx_tup_fetch

These are the number of rows fetched from the table as a result of an index scan. This is increased as a result of both positive and false positive results. For example, if both ids exist, the query

select * from finance.transfer
 where (transfer_created_at, transaction_account, counterparty_account) in
       (('2025-11-25 18:04:26.298329+00'::timestamptz, 'acc_8', 'acc_15'),
       ('2025-11-25 01:39:36.594342+00'::timestamptz, 'acc_11', 'acc_9'))
 and transfer_status='completed';

will increase idx_tup_fetch by 2 even if only one tuple is returned to the client. The reason is that the tuples will need to be loaded from disk to examine the value of ‘transfer_status’.

OLTP

In OLTP workloads, the DBMS needs to quickly read and write individual rows of data while ensuring data integrity(Datta 2024).

Below we showcase some interesting OLTP workflows on the feature list:

Listing

Listing should be simple enough, but it contains traps for if one uses the naive OFFSET approach(Winand, n.d.):

the pages drift when inserting new sales because the numbering is always done from scratch;

the response time increases when browsing further back.

Proper pagination

In order to avoid the problems above, we need to leverage the primary key index directly by using values instead of offsets. Given that we are listing all transfers/transactions for a given account sorted by time, this maps directly to the composite primary key index, allowing PostgreSQL to do an equality match on the first two columns and then a backward index scan from the cursor position on transfer_created_at:

select *
  from finance.transfer
 where routing_number = ?
   and account_number = ?
   and transfer_created_at < ?
 order by transfer_created_at desc
 fetch first 10 rows only;

Primary Key Column Order

In order to enable the listing above, the primary key definition needs to reflect the access pattern:

routing_number, account_number - identifies the account (most selective)
transfer_created_at - enables efficient time-range queries on account transfers, which enables the pagination
counterparty_routing_number, counterparty_account_number - completes the transfer identity

The history of a transfer

In order to implement feature 5, we need to query the full state history of transfers intermingling it with the proper transactions. We define this as a view, since it represents a derived relation that will be reused throughout the system:

create or replace view finance.transfer_activity as
select 'transfer' as kind,
       t.routing_number,
       t.account_number,
       t.counterparty_routing_number,
       t.counterparty_account_number,
       t.amount,
       t.status,
       t.transfer_created_at as created_at
  from finance.transfer t

union all

select 'transfer_history' as kind,
       h.routing_number,
       h.account_number,
       h.counterparty_routing_number,
       h.counterparty_account_number,
       h.amount,
       h.status,
       h.transfer_created_at as created_at
  from finance.transfer_status_log h

union all

select 'pending_transaction' as kind,
       pt.routing_number,
       pt.account_number,
       pt.counterparty_routing_number,
       pt.counterparty_account_number,
       pt.amount,
       'pending' as status,
       pt.transaction_created_at as created_at
  from finance.pending_transaction pt

union all

select 'settled_transaction' as kind,
       st.routing_number,
       st.account_number,
       st.counterparty_routing_number,
       st.counterparty_account_number,
       st.amount,
       'settled' as status,
       st.transaction_created_at as created_at
  from finance.settled_transaction st;

comment on view finance.transfer_activity is
  'Unified view of the full history of transfers and their associated
   transactions. Each row is tagged with a kind discriminator. Used for
   transfer history display and as the foundation for the updatable
   interface defined in the On decoupling section.';

Querying the full history of a specific transfer is now a simple filter on the view:

select *
  from finance.transfer_activity
 where routing_number = ?
   and account_number = ?
   and counterparty_routing_number = ?
   and counterparty_account_number = ?
 order by created_at;

OLAP

In OLAP workloads, the DBMS needs manage large volumes of data while allowing for quick query response times(Datta 2024). Calculating account balances, which is what we need to do in order to implement requirement 4, fit squarely into that category.

As a reminder, we need to compute two balances per account, queryable at any point in time:

Current balance: the balance you earn interest on, derived from settled transactions only.
Available balance: the amount you’re able to move out, derived from both settled and pending transactions.

Obviously scanning the full transaction history and computing the sum using a row oriented DBMS like PostgreSQL would yield correct results, but it would certainly not be quick. Worse, as the transaction table grows, every balance query becomes a range scan over an ever-larger set of rows.

One solution is to maintain a balance ledger incrementally via triggers. The principle is the same one behind incremental view maintenance: the cost of keeping derived data up to date is borne by the process changing the base data, with the extra operations added to the execution plan of the original insert(White 2015). We shift work from read time to write time.

In our case, this trade-off is acceptable: transactions are append-only (no updates or deletes), and per account, we don’t expect a swarm of concurrent transactions. The write overhead of maintaining the balance ledger is small compared to the read savings of never having to aggregate the full transaction history.

Balance ledger

The finance.balance_ledger table stores a snapshot of both balances after every transaction. Each row records the cumulative totals as of that transaction’s timestamp, enabling queries like “what was the balance at close of business yesterday?” via a single index-backed lookup.

create table finance.balance_ledger (
  routing_number  finance.routing_number not null,
  account_number  finance.account_number not null,
  as_of           timestamptz not null,
  current_total   bigint not null,
  available_total bigint not null,
  primary key (routing_number, account_number, as_of)
);

comment on table finance.balance_ledger is
  'Running balance snapshots per account. Each row records the cumulative
   current and available totals as of a given transaction timestamp.
   Maintained incrementally by triggers on settled and pending transaction
   inserts. Current total reflects settled transactions only. Available
   total reflects both settled and pending transactions.';

revoke update, delete on finance.balance_ledger from finance;

Incremental maintenance via triggers

When a settled transaction is inserted, both the current and available totals change. When a pending transaction is inserted, only the available total changes. Each trigger fetches the most recent ledger row for the account and appends a new snapshot with the updated running totals.

create or replace function finance.update_balance_on_settled()
  returns trigger language plpgsql as $$
declare
  v_current   bigint;
  v_available bigint;
begin
  select current_total, available_total
    into v_current, v_available
    from finance.balance_ledger
   where routing_number = NEW.routing_number
     and account_number = NEW.account_number
   order by as_of desc
   limit 1;

  if not found then
    v_current   := 0;
    v_available := 0;
  end if;

  insert into finance.balance_ledger
    (routing_number, account_number, as_of, current_total, available_total)
  values
    (NEW.routing_number, NEW.account_number, NEW.transaction_created_at,
     v_current + NEW.amount, v_available + NEW.amount);

  return NEW;
end;
$$;

create trigger settled_update_balance
  after insert on finance.settled_transaction
  for each row
  execute function finance.update_balance_on_settled();

create or replace function finance.update_balance_on_pending()
  returns trigger language plpgsql as $$
declare
  v_current   bigint;
  v_available bigint;
begin
  select current_total, available_total
    into v_current, v_available
    from finance.balance_ledger
   where routing_number = NEW.routing_number
     and account_number = NEW.account_number
   order by as_of desc
   limit 1;

  if not found then
    v_current   := 0;
    v_available := 0;
  end if;

  insert into finance.balance_ledger
    (routing_number, account_number, as_of, current_total, available_total)
  values
    (NEW.routing_number, NEW.account_number, NEW.transaction_created_at,
     v_current, v_available + NEW.amount);

  return NEW;
end;
$$;

create trigger pending_update_balance
  after insert on finance.pending_transaction
  for each row
  execute function finance.update_balance_on_pending();

With this design, querying the balance at any point in time is a simple index-backed lookup:

-- Balance as of a specific timestamp
select current_total, available_total
  from finance.balance_ledger
 where routing_number = ?
   and account_number = ?
   and as_of <= ?
 order by as_of desc
 fetch first 1 row only;

-- Latest balance
select current_total, available_total
  from finance.balance_ledger
 where routing_number = ?
   and account_number = ?
 order by as_of desc
 fetch first 1 row only;

On serializable isolation

The constraint triggers in the constraints section and the balance ledger triggers in the OLAP section share a common vulnerability under PostgreSQL’s default READ COMMITTED isolation level: they all follow a read-then-write pattern. A transaction reads some state (a transfer’s status, a transfer’s period bounds, the latest balance row), makes a decision based on that state, and then writes. Under READ COMMITTED, concurrent transactions can each read a snapshot that does not reflect the other’s uncommitted changes, and both proceed to write, producing an inconsistent result.

Concrete examples:

Lost balance updates: Two concurrent inserts into settled_transaction for the same account both read the latest balance_ledger row as current_total = 1000. Both insert a new ledger row with current_total = 1000 + amount, when the second should have been 1000 + amount_A + amount_B. The running total is silently corrupted.
Pending transaction against a closing transfer: ensure_pending_transfer reads the transfer as status = 'pending' and allows the insert. Concurrently, another transaction updates the transfer to completed. Both commit, and a pending transaction now references a completed transfer.
Transaction outside transfer period: transaction_within_transfer_period reads the transfer period as open and allows the insert. Concurrently, the transfer’s period is being closed by a status transition. Both commit, and a transaction exists outside its transfer’s period.
Future transaction slipping past closure: no_future_transactions_on_close checks for future transactions and finds none. Concurrently, another transaction inserts one. Both commit, and the transfer is closed with a transaction stranded after the closure time.

All of these are instances of the same fundamental problem: write skew under snapshot isolation. The solution is SERIALIZABLE isolation:

alter role finance set default_transaction_isolation = 'serializable';

Under PostgreSQL’s Serializable Snapshot Isolation (SSI), the engine tracks read-write dependencies between concurrent transactions. When it detects a dependency cycle that could produce a result impossible under any serial execution, it aborts one of the transactions with a serialization failure. The application must be prepared to retry aborted transactions, but the data invariants are never violated.

This is a global setting because the problem is global: every read-then-write constraint trigger and every incremental balance update is vulnerable. Setting isolation per-transaction would require the application to know which transactions touch which tables, and a single missed annotation would silently open a consistency hole. The database default eliminates that risk.

The cost is that some transactions will be aborted and must be retried. In our case, this cost is low: the serialization conflicts occur only between concurrent writes to the same account, and per account, we don’t expect a swarm of concurrent transactions. The application can use straightforward retry logic such as exponential backoff(Brooker 2015). The alternative of risking silent data corruption is certainly not acceptable in a financial system.

On decoupling

Views are the canonical way to implement modularity in SQL DBMSes like PostgreSQL(Bellani 2024). As Codd originally envisioned, views provide logical data independence: application programs and terminal activities remain unaffected when the internal representation of data changes(Codd 1970). In non-alien language: the relation between interfaces (views) and implementations (base tables) is many-to-many, which is precisely the definition of modularity(Koppel 2023).

This means that instead of reaching for microservices to achieve decoupling — with all their attendant costs in serialization overhead, distributed consistency problems, and operational complexity(Ghemawat et al. 2023) — we can achieve the same logical property using views over a single PostgreSQL instance.

The finance.transfer_activity view defined in the history of a transfer section already provides a stable read interface. Now we make it updatable, turning it into the single interface through which applications insert transfers and transactions, and update transfer status:

create or replace function finance.transfer_activity_insert()
  returns trigger language plpgsql as $$
begin
  case NEW.kind
    when 'transfer' then
      insert into finance.transfer
        (routing_number, account_number,
         counterparty_routing_number, counterparty_account_number,
         amount)
      values
        (NEW.routing_number, NEW.account_number,
         NEW.counterparty_routing_number, NEW.counterparty_account_number,
         NEW.amount);

    when 'pending_transaction' then
      insert into finance.pending_transaction
        (routing_number, account_number,
         counterparty_routing_number, counterparty_account_number,
         transfer_created_at, amount)
      values
        (NEW.routing_number, NEW.account_number,
         NEW.counterparty_routing_number, NEW.counterparty_account_number,
         NEW.created_at, NEW.amount);

    when 'settled_transaction' then
      insert into finance.settled_transaction
        (routing_number, account_number,
         counterparty_routing_number, counterparty_account_number,
         transfer_created_at, amount)
      values
        (NEW.routing_number, NEW.account_number,
         NEW.counterparty_routing_number, NEW.counterparty_account_number,
         NEW.created_at, NEW.amount);

    else
      raise exception 'Unknown kind: %. Must be transfer, pending_transaction, or settled_transaction', NEW.kind;
  end case;

  return NEW;
end;
$$;

create trigger transfer_activity_insert_trigger
  instead of insert on finance.transfer_activity
  for each row
  execute function finance.transfer_activity_insert();

create or replace function finance.transfer_activity_update()
  returns trigger language plpgsql as $$
begin
  if OLD.kind <> 'transfer' then
    raise exception 'Only current transfers can be updated, not %', OLD.kind;
  end if;

  update finance.transfer
     set status = NEW.status
   where routing_number              = OLD.routing_number
     and account_number              = OLD.account_number
     and transfer_created_at         = OLD.created_at
     and counterparty_routing_number = OLD.counterparty_routing_number
     and counterparty_account_number = OLD.counterparty_account_number;

  return NEW;
end;
$$;

create trigger transfer_activity_update_trigger
  instead of update on finance.transfer_activity
  for each row
  execute function finance.transfer_activity_update();

Applications interact with finance.transfer_activity as a single unified stream. They can:

Read the full history of a transfer and its transactions, filtered by account and transfer identity, ordered by time.
Insert new transfers (kind = 'transfer'), pending transactions (kind = 'pending_transaction'), or settled transactions (kind = 'settled_transaction'). The INSTEAD OF trigger routes each insert to the correct underlying table, where all constraint triggers, temporal foreign keys, and balance ledger maintenance fire as usual. For transactions, created_at identifies the originating transfer.
Update a transfer’s status by updating a row where kind = 'transfer'. The INSTEAD OF trigger routes the status change to finance.transfer, where the state machine trigger and all constraint triggers fire as usual.

If the underlying table structure changes — columns are renamed, new columns are added, tables are split or merged — the view definition is updated once, and every application continues to work unchanged.

This is decoupling achieved at the data level, with no network hops, no serialization overhead, and no distributed consistency problems. The view is the interface, and the base tables are the implementation.

Benchmarking the startup scenario

To validate the design under realistic conditions, we use pgbench with custom scripts that exercise the full write and read paths through the finance.transfer_activity view. The scenario models the startup tier from the capacity planning section: 10,000 transfers per day with an 80/20 read/write split.

Seed data

First, we seed 100 managed and 100 external accounts:

-- Seed external accounts
insert into finance.external_account (routing_number, account_number, account_name)
select lpad(i::text, 9, '0'),
       lpad(i::text, 12, '0'),
       'External Account ' || i
  from generate_series(1, 100) as i
on conflict do nothing;

-- Seed managed accounts
insert into finance.managed_active_account (routing_number, account_number, account_name)
select lpad((i + 100)::text, 9, '0'),
       lpad((i + 100)::text, 12, '0'),
       'Managed Account ' || i
  from generate_series(1, 100) as i
on conflict do nothing;

Write script: full transfer lifecycle

Each invocation of this script exercises the complete lifecycle through the updatable view: create a transfer, insert a pending transaction, then complete the transfer and insert a settled transaction. Transfer creation and the pending transaction each run in their own transaction, mirroring how a real application would process these at different points in time. The completion and settled transaction are grouped in a single transaction because the state machine closes the transfer period with now(), and the settled transaction’s transaction_created_at (which also defaults to now()) must fall within that period. Every constraint trigger, the state machine, the temporal foreign key, and the balance ledger triggers all fire on each run.

\set managed_id random(1, 100)
\set external_id random(1, 100)
\set amount random(100, 100000)

-- 1. Create transfer via the view
insert into finance.transfer_activity
  (kind, routing_number, account_number,
   counterparty_routing_number, counterparty_account_number, amount)
values
  ('transfer',
   lpad((:managed_id + 100)::text, 9, '0'),
   lpad((:managed_id + 100)::text, 12, '0'),
   lpad(:external_id::text, 9, '0'),
   lpad(:external_id::text, 12, '0'),
   :amount);

-- 2. Retrieve the transfer we just created
select created_at as xfer_ts
  from finance.transfer_activity
 where kind = 'transfer'
   and routing_number = lpad((:managed_id + 100)::text, 9, '0')
   and account_number = lpad((:managed_id + 100)::text, 12, '0')
   and counterparty_routing_number = lpad(:external_id::text, 9, '0')
   and counterparty_account_number = lpad(:external_id::text, 12, '0')
   and status = 'pending'
 order by created_at desc
 fetch first 1 row only
\gset

-- 3. Insert pending transaction via the view (transfer is still pending)
insert into finance.transfer_activity
  (kind, routing_number, account_number,
   counterparty_routing_number, counterparty_account_number,
   created_at, amount)
values
  ('pending_transaction',
   lpad((:managed_id + 100)::text, 9, '0'),
   lpad((:managed_id + 100)::text, 12, '0'),
   lpad(:external_id::text, 9, '0'),
   lpad(:external_id::text, 12, '0'),
   ':xfer_ts', :amount);

-- 4. Complete the transfer and insert settled transaction atomically.
--    This ensures now() is the same for the period close and the
--    settled transaction's transaction_created_at.
begin;

update finance.transfer_activity
   set status = 'completed'
 where kind = 'transfer'
   and routing_number = lpad((:managed_id + 100)::text, 9, '0')
   and account_number = lpad((:managed_id + 100)::text, 12, '0')
   and counterparty_routing_number = lpad(:external_id::text, 9, '0')
   and counterparty_account_number = lpad(:external_id::text, 12, '0')
   and created_at = ':xfer_ts';

insert into finance.transfer_activity
  (kind, routing_number, account_number,
   counterparty_routing_number, counterparty_account_number,
   created_at, amount)
values
  ('settled_transaction',
   lpad((:managed_id + 100)::text, 9, '0'),
   lpad((:managed_id + 100)::text, 12, '0'),
   lpad(:external_id::text, 9, '0'),
   lpad(:external_id::text, 12, '0'),
   ':xfer_ts', :amount);

commit;

Read script: activity stream and balance

Each invocation queries the transfer activity stream for a random account (paginated) and its latest balance:

\set managed_id random(1, 100)

-- Read transfer activity stream (latest 20 entries)
select *
  from finance.transfer_activity
 where routing_number = lpad((:managed_id + 100)::text, 9, '0')
   and account_number = lpad((:managed_id + 100)::text, 12, '0')
 order by created_at desc
 fetch first 20 rows only;

-- Read latest balance
select current_total, available_total
  from finance.balance_ledger
 where routing_number = lpad((:managed_id + 100)::text, 9, '0')
   and account_number = lpad((:managed_id + 100)::text, 12, '0')
 order by as_of desc
 fetch first 1 row only;

Running the benchmark

# 1. Apply the full schema (Appendix A)
psql -f only_postgres_code.sql

# 2. Seed accounts
psql -f pgbench_setup.sql

# 3. Run 80/20 read/write mix for 60 seconds
#    @4 = weight 4 (80%), @1 = weight 1 (20%)
#    -c 10: 10 concurrent clients
#    -j 4:  4 worker threads
#    -P 5:  progress every 5 seconds
#    -T 60: run for 60 seconds
pgbench -h localhost -p 54321 -U admin -d blog \
        --no-vacuum \
        -f pgbench_read.sql@4 \
        -f pgbench_write.sql@1 \
        -c 10 -j 4 -T 60 -P 5

Results

pgbench (18.4)
transaction type: multiple scripts
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 4
maximum number of tries: 1
duration: 60 s
number of transactions actually processed: 45985
number of failed transactions: 0 (0.000%)
latency average = 13.044 ms
latency stddev = 12.449 ms
initial connection time = 17.840 ms
tps = 766.151693 (without initial connection time)
SQL script 1: pgbench_read.sql
 - weight: 4 (targets 80.0% of total)
 - 36793 transactions (80.0% of total)
 - latency average = 8.080 ms
 - latency stddev = 6.135 ms
SQL script 2: pgbench_write.sql
 - weight: 1 (targets 20.0% of total)
 - 9191 transactions (20.0% of total)
 - latency average = 32.915 ms
 - latency stddev = 11.455 ms

Key takeaways:

766 TPS overall with 0 failed transactions. The startup target of 10,000 transfers/day is ~0.12 TPS. We exceed that by over 6,000x, confirming massive headroom on modest hardware.
0 serialization failures: Despite 10 concurrent clients writing to 100 accounts under SERIALIZABLE isolation, no transactions were aborted. The working set is distributed across enough accounts that write contention is negligible at this scale.
8ms average read latency: The UNION ALL view over 4 tables plus the balance ledger lookup completes well within interactive response time, even as the tables grow throughout the 60-second run.
33ms average write latency: Each write transaction exercises the full constraint set that implements complex business logic (audit trails, time constraints, balances, etc) all within 33ms. This is the true cost of enforcing every business rule at the data level, and it is more than acceptable.

These results were obtained on a development laptop, not production hardware. On an RDS instance sized for the working set (as described in the capacity planning section), performance would be significantly better.

Conclusion

We set out to show that the default assumption for your data problems should be that your company can do fine with just PostgreSQL. Let’s revisit each objection from the setup and see how it was addressed:

I’ll need auditing and reconstructing state: System-time temporal tables (transfer state history) give you a complete, automatic audit trail of every transfer status transition. No event store, no append-only log infrastructure — just a history table maintained by a trigger.
Write throughput is too low: By keeping the working set (2 days of transfers and transactions) sized to fit in shared_buffers, and by aligning indexes with immutable columns to enable HOT updates that eliminate write amplification on transfer status transitions, we maximize write performance without any external caching layer.
The transactional queries are too slow: Keyset pagination over composite primary keys, as shown in the OLTP section, gives stable, index-backed listing performance that doesn’t degrade as you page deeper. Transfer history queries are a single UNION ALL over indexed tables.
The analytical queries are too slow: The balance ledger maintains running balance snapshots incrementally via triggers, turning what would be a full-table aggregation into a single index-backed lookup at any point in time.
My app will be coupled to the Database: The updatable view finance.transfer_activity serves as a stable interface for reading activity, inserting transfers and transactions, and updating transfer status through a single unified stream. If the underlying tables change, the view definition is updated once and every application continues to work unchanged. This is modularity achieved at the data level(Bellani 2024), with no network hops, no serialization overhead, and no distributed consistency problems(Ghemawat et al. 2023).

All of this runs on a single vanilla PostgreSQL 18 instance with standard extensions available on RDS. No distributed-systems cosplay, no infrastructure proliferation, no operational complexity tax. We have only scratched the surface of what is available both in PostgreSQL as a SQL engine and in relational theory properly understood.

Figure 3: 1936 fire in the Sagrada Familia, set by communist revolutionaries

Appendix A: Full code suite.

create schema finance;

create role finance;
grant usage on schema finance to finance;
alter default privileges in schema finance
  grant select, insert, update, delete on tables to finance;

alter default privileges in schema finance
  grant usage, select on sequences to finance;
create domain finance.routing_number as text
check (value ~ '^[0-9]{9}$');

create domain finance.account_number as text
  check (value ~ '^[0-9]{12}$');

create domain finance.transfer_status as text
  check(value in ('pending',
                  'returned',
                  'completed'));
-- To use temporal constraints, you need to install the btree_gist extension, which provides the necessary operator classes for creating GiST indexes on scalar data types:
create extension if not exists btree_gist;

create table finance.managed_active_account(
  routing_number  finance.routing_number not null,
  account_number  finance.account_number not null,
  account_name    text not null,
  account_active_period tstzrange not null default tstzrange(now(), 'infinity', '[)'),
  primary key (routing_number,
               account_number,
               account_active_period without overlaps)
);

comment on table finance.managed_active_account is
  'Managed Accounts are what transactions are performed against. Think of your bank account. They store money, receive transfers, and send payments. They earn interest and have depository insurance. This relation holds the accounts that are active. No transfer may be created for accounts in the period that they were inactive.';

create table finance.external_account(
  routing_number  finance.routing_number not null,
  account_number  finance.account_number not null,
  account_name    text not null,
  primary key (routing_number, account_number)
);

comment on table finance.external_account is
  'External accounts represent counterparty accounts at other institutions. They are the other side of a transfer. Unlike managed accounts, they have no temporal active period since we do not control their lifecycle.';
-- Ensure managed and external accounts never share the same identity
create or replace function finance.not_external_account(
  p_routing_number finance.routing_number,
  p_account_number finance.account_number
)
  returns boolean language sql stable as $$
  select not exists (
    select 1
      from finance.external_account
     where routing_number = p_routing_number
       and account_number = p_account_number
  );
$$;

create or replace function finance.not_managed_account(
  p_routing_number finance.routing_number,
  p_account_number finance.account_number
)
  returns boolean language sql stable as $$
  select not exists (
    select 1
      from finance.managed_active_account
     where routing_number = p_routing_number
       and account_number = p_account_number
  );
$$;

alter table finance.managed_active_account
  add constraint managed_not_external
  check (finance.not_external_account(routing_number, account_number));

alter table finance.external_account
  add constraint external_not_managed
check (finance.not_managed_account(routing_number, account_number));
create table finance.transfer (
  transfer_period             tstzrange not null default tstzrange(now(), 'infinity', '[)'),
  transfer_created_at         timestamptz
                              generated always as (lower(transfer_period)) stored,
  account_number              finance.account_number not null,
  routing_number              finance.routing_number not null,
  counterparty_account_number finance.account_number not null,
  counterparty_routing_number finance.routing_number not null,
  amount                      bigint not null,
  status                      finance.transfer_status not null default 'pending',
  -- Natural order: account identity, then time, then counterparty
  -- This enables efficient time-range queries on account transfers
  primary key (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number
  ),
  foreign key (
    counterparty_routing_number,
    counterparty_account_number
  ) references finance.external_account (
    routing_number,
    account_number
  ),
  -- temporal foreign key: ensure managed account exists during transfer period
  foreign key (
    routing_number,
    account_number,
    period transfer_period
  ) references finance.managed_active_account (
    routing_number,
    account_number,
    period account_active_period
  )
);

comment on table finance.transfer is
  'Transfers represent money movement between an external account and a managed account. Status follows state machine: pending -> (completed | returned). Period closes on terminal state. transfer_created_at is a stored generated column derived from lower(transfer_period), eliminating redundancy while remaining usable in primary keys and foreign key references.';

revoke insert on finance.transfer from finance;
revoke update on finance.transfer from finance;
-- transfer_period will be managed based on the status
grant insert (routing_number,
              account_number,
              counterparty_routing_number,
              counterparty_account_number,
              amount) on finance.transfer to finance;
grant update (status) on finance.transfer to finance;
-- Add system-time period column to transfer table
alter table finance.transfer add column if not exists sys_period tstzrange default tstzrange(current_timestamp, null);
alter table finance.transfer alter column sys_period set not null;

-- Focused history table - only what we need for status transitions
create table if not exists finance.transfer_status_log (
  like finance.transfer
);

comment on table finance.transfer_status_log is
  'Automatic log of all transfer status transitions via temporal_tables extension. Shows complete state machine history.';

alter table finance.transfer_status_log
  add primary key (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number,
    sys_period
  );

-- Use temporal_tables versioning procedure
create trigger transfer_save_status_history
  before insert or update or delete
  on finance.transfer
  for each row
  execute procedure versioning('sys_period', 'finance.transfer_status_log', true);
-- Add system-time period column to the account table
alter table finance.managed_active_account add column if not exists sys_period tstzrange default tstzrange(current_timestamp, null);
alter table finance.managed_active_account alter column sys_period set not null;

create table if not exists finance.managed_active_account_log (
  like finance.managed_active_account
);

comment on table finance.managed_active_account_log is
  'Automatic log of all account activity via temporal_tables extension.';

create index on finance.managed_active_account_log (sys_period);
create index on finance.managed_active_account_log (routing_number, account_number);

-- Use temporal_tables versioning procedure
create trigger account_save_history
  before insert or update or delete
  on finance.managed_active_account
  for each row
  execute procedure versioning('sys_period', 'finance.managed_active_account_log', true);
create table finance.settled_transaction (
  transaction_created_at      timestamptz not null default now(),
  account_number              finance.account_number not null,
  routing_number              finance.routing_number not null,
  counterparty_account_number finance.account_number not null,
  counterparty_routing_number finance.routing_number not null,
  transfer_created_at         timestamptz not null,
  amount                      bigint not null,
  primary key (
    account_number,
    routing_number,
    transaction_created_at
  ),
  foreign key (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number
  )
  references finance.transfer (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number
  )
);

comment on table finance.settled_transaction is
  'Settled transactions affect both your available balance and your current balance. They are immutable events --- no updates or deletes permitted.';

revoke update, delete on finance.settled_transaction from finance;

create table finance.pending_transaction (
  like finance.settled_transaction including all,
  foreign key (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number
  )
  references finance.transfer (
    routing_number,
    account_number,
    transfer_created_at,
    counterparty_routing_number,
    counterparty_account_number
  )
);

comment on table finance.pending_transaction is
  'Pending transactions represent potential future credits or debits. They affect available balance but not current balance. Immutable once created.';

revoke update, delete on finance.pending_transaction from finance;
create or replace function finance.enforce_transfer_state_machine()
  returns trigger language plpgsql as $$
begin
  if OLD.status = NEW.status then
    return NEW;
  end if;

  if OLD.status = 'pending' then
    if NEW.status not in ('completed', 'returned') then
      raise exception 'Invalid state transition: pending can only transition to completed or returned, not %', NEW.status;
    end if;
    NEW.transfer_period := tstzrange(lower(OLD.transfer_period), now(), '[]');

  elsif OLD.status in ('completed', 'returned') then
    raise exception 'Invalid state transition: % is a terminal state and cannot transition to %', OLD.status, NEW.status;
  end if;

  return NEW;
end;
$$;

create trigger transfer_z_enforce_state_machine
  before update of status on finance.transfer
  for each row
  when (OLD.status <> NEW.status)
  execute function finance.enforce_transfer_state_machine();
create or replace function finance.transaction_within_transfer_period()
  returns trigger language plpgsql as $$
declare
  v_transfer_period tstzrange;
begin
  select transfer_period into v_transfer_period
    from finance.transfer
   where routing_number              = NEW.routing_number
     and account_number              = NEW.account_number
     and transfer_created_at         = NEW.transfer_created_at
     and counterparty_routing_number = NEW.counterparty_routing_number
     and counterparty_account_number = NEW.counterparty_account_number;

  if not found then
    raise exception 'Transfer not found for transaction';
  end if;

  if not (v_transfer_period @> NEW.transaction_created_at) then
    raise exception
      'Transaction created_at % is outside transfer period %',
      NEW.transaction_created_at, v_transfer_period;
  end if;

  return NEW;
end;
$$;

create constraint trigger settled_transaction_within_transfer_period
  after insert on finance.settled_transaction
  deferrable initially deferred
  for each row
  execute function finance.transaction_within_transfer_period();

create constraint trigger pending_transaction_within_transfer_period
  after insert on finance.pending_transaction
  deferrable initially deferred
  for each row
  execute function finance.transaction_within_transfer_period();
create or replace function finance.is_pending_transfer(
  p_routing_number finance.routing_number,
  p_account_number finance.account_number,
  p_transfer_created_at timestamptz,
  p_counterparty_routing_number finance.routing_number,
  p_counterparty_account_number finance.account_number
)
  returns boolean language sql stable as $$
  select exists (
    select 1
      from finance.transfer t
     where t.routing_number              = p_routing_number
       and t.account_number              = p_account_number
       and t.transfer_created_at         = p_transfer_created_at
       and t.counterparty_routing_number = p_counterparty_routing_number
       and t.counterparty_account_number = p_counterparty_account_number
       and t.status                      = 'pending'
  );
$$;

create or replace function finance.ensure_pending_transfer()
  returns trigger language plpgsql as $$
begin
  if not finance.is_pending_transfer(
    NEW.routing_number,
    NEW.account_number,
    NEW.transfer_created_at,
    NEW.counterparty_routing_number,
    NEW.counterparty_account_number
  ) then
    raise exception
      'Must reference a pending transfer (%, %, %, %, %)',
      NEW.routing_number, NEW.account_number, NEW.transfer_created_at,
      NEW.counterparty_routing_number, NEW.counterparty_account_number;
  end if;
  return NEW;
end;
$$;

create or replace function finance.ensure_non_pending_transfer()
  returns trigger language plpgsql as $$
begin
  if finance.is_pending_transfer(
    NEW.routing_number,
    NEW.account_number,
    NEW.transfer_created_at,
    NEW.counterparty_routing_number,
    NEW.counterparty_account_number
  ) then
    raise exception
      'Cannot reference a pending transfer (%, %, %, %, %)',
      NEW.routing_number, NEW.account_number, NEW.transfer_created_at,
      NEW.counterparty_routing_number, NEW.counterparty_account_number;
  end if;
  return NEW;
end;
$$;

create constraint trigger pending_transaction_requires_pending_transfer
  after insert on finance.pending_transaction
  deferrable initially deferred
  for each row
  execute function finance.ensure_pending_transfer();

create constraint trigger settled_transaction_requires_non_pending_transfer
  after insert on finance.settled_transaction
  deferrable initially deferred
  for each row
  execute function finance.ensure_non_pending_transfer();
create or replace function finance.no_future_transactions_on_close()
  returns trigger language plpgsql as $$
begin
  if exists (
    select 1 from finance.settled_transaction
     where routing_number              = NEW.routing_number
       and account_number              = NEW.account_number
       and transfer_created_at         = NEW.transfer_created_at
       and counterparty_routing_number = NEW.counterparty_routing_number
       and counterparty_account_number = NEW.counterparty_account_number
       and transaction_created_at > now()
    union all
    select 1 from finance.pending_transaction
     where routing_number              = NEW.routing_number
       and account_number              = NEW.account_number
       and transfer_created_at         = NEW.transfer_created_at
       and counterparty_routing_number = NEW.counterparty_routing_number
       and counterparty_account_number = NEW.counterparty_account_number
       and transaction_created_at > now()
  ) then
    raise exception
      'Cannot close transfer (%, %, %): transaction(s) exist after current time',
      NEW.routing_number, NEW.account_number, NEW.transfer_created_at;
  end if;

  return NEW;
end;
$$;

create constraint trigger transfer_no_future_transactions_on_close
  after update of status on finance.transfer
  deferrable initially deferred
  for each row
  when (NEW.status in ('completed', 'returned'))
  execute function finance.no_future_transactions_on_close();
create or replace view finance.transfer_activity as
select 'transfer' as kind,
       t.routing_number,
       t.account_number,
       t.counterparty_routing_number,
       t.counterparty_account_number,
       t.amount,
       t.status,
       t.transfer_created_at as created_at
  from finance.transfer t

union all

select 'transfer_history' as kind,
       h.routing_number,
       h.account_number,
       h.counterparty_routing_number,
       h.counterparty_account_number,
       h.amount,
       h.status,
       h.transfer_created_at as created_at
  from finance.transfer_status_log h

union all

select 'pending_transaction' as kind,
       pt.routing_number,
       pt.account_number,
       pt.counterparty_routing_number,
       pt.counterparty_account_number,
       pt.amount,
       'pending' as status,
       pt.transaction_created_at as created_at
  from finance.pending_transaction pt

union all

select 'settled_transaction' as kind,
       st.routing_number,
       st.account_number,
       st.counterparty_routing_number,
       st.counterparty_account_number,
       st.amount,
       'settled' as status,
       st.transaction_created_at as created_at
  from finance.settled_transaction st;

comment on view finance.transfer_activity is
  'Unified view of the full history of transfers and their associated
   transactions. Each row is tagged with a kind discriminator. Used for
   transfer history display and as the foundation for the updatable
   interface defined in the On decoupling section.';
create table finance.balance_ledger (
  routing_number  finance.routing_number not null,
  account_number  finance.account_number not null,
  as_of           timestamptz not null,
  current_total   bigint not null,
  available_total bigint not null,
  primary key (routing_number, account_number, as_of)
);

comment on table finance.balance_ledger is
  'Running balance snapshots per account. Each row records the cumulative
   current and available totals as of a given transaction timestamp.
   Maintained incrementally by triggers on settled and pending transaction
   inserts. Current total reflects settled transactions only. Available
   total reflects both settled and pending transactions.';

revoke update, delete on finance.balance_ledger from finance;
create or replace function finance.update_balance_on_settled()
  returns trigger language plpgsql as $$
declare
  v_current   bigint;
  v_available bigint;
begin
  select current_total, available_total
    into v_current, v_available
    from finance.balance_ledger
   where routing_number = NEW.routing_number
     and account_number = NEW.account_number
   order by as_of desc
   limit 1;

  if not found then
    v_current   := 0;
    v_available := 0;
  end if;

  insert into finance.balance_ledger
    (routing_number, account_number, as_of, current_total, available_total)
  values
    (NEW.routing_number, NEW.account_number, NEW.transaction_created_at,
     v_current + NEW.amount, v_available + NEW.amount);

  return NEW;
end;
$$;

create trigger settled_update_balance
  after insert on finance.settled_transaction
  for each row
  execute function finance.update_balance_on_settled();

create or replace function finance.update_balance_on_pending()
  returns trigger language plpgsql as $$
declare
  v_current   bigint;
  v_available bigint;
begin
  select current_total, available_total
    into v_current, v_available
    from finance.balance_ledger
   where routing_number = NEW.routing_number
     and account_number = NEW.account_number
   order by as_of desc
   limit 1;

  if not found then
    v_current   := 0;
    v_available := 0;
  end if;

  insert into finance.balance_ledger
    (routing_number, account_number, as_of, current_total, available_total)
  values
    (NEW.routing_number, NEW.account_number, NEW.transaction_created_at,
     v_current, v_available + NEW.amount);

  return NEW;
end;
$$;

create trigger pending_update_balance
  after insert on finance.pending_transaction
  for each row
  execute function finance.update_balance_on_pending();
alter role finance set default_transaction_isolation = 'serializable';
create or replace function finance.transfer_activity_insert()
  returns trigger language plpgsql as $$
begin
  case NEW.kind
    when 'transfer' then
      insert into finance.transfer
        (routing_number, account_number,
         counterparty_routing_number, counterparty_account_number,
         amount)
      values
        (NEW.routing_number, NEW.account_number,
         NEW.counterparty_routing_number, NEW.counterparty_account_number,
         NEW.amount);

    when 'pending_transaction' then
      insert into finance.pending_transaction
        (routing_number, account_number,
         counterparty_routing_number, counterparty_account_number,
         transfer_created_at, amount)
      values
        (NEW.routing_number, NEW.account_number,
         NEW.counterparty_routing_number, NEW.counterparty_account_number,
         NEW.created_at, NEW.amount);

    when 'settled_transaction' then
      insert into finance.settled_transaction
        (routing_number, account_number,
         counterparty_routing_number, counterparty_account_number,
         transfer_created_at, amount)
      values
        (NEW.routing_number, NEW.account_number,
         NEW.counterparty_routing_number, NEW.counterparty_account_number,
         NEW.created_at, NEW.amount);

    else
      raise exception 'Unknown kind: %. Must be transfer, pending_transaction, or settled_transaction', NEW.kind;
  end case;

  return NEW;
end;
$$;

create trigger transfer_activity_insert_trigger
  instead of insert on finance.transfer_activity
  for each row
  execute function finance.transfer_activity_insert();

create or replace function finance.transfer_activity_update()
  returns trigger language plpgsql as $$
begin
  if OLD.kind <> 'transfer' then
    raise exception 'Only current transfers can be updated, not %', OLD.kind;
  end if;

  update finance.transfer
     set status = NEW.status
   where routing_number              = OLD.routing_number
     and account_number              = OLD.account_number
     and transfer_created_at         = OLD.created_at
     and counterparty_routing_number = OLD.counterparty_routing_number
     and counterparty_account_number = OLD.counterparty_account_number;

  return NEW;
end;
$$;

create trigger transfer_activity_update_trigger
  instead of update on finance.transfer_activity
  for each row
  execute function finance.transfer_activity_update();

Code Snippet 1: Full code listing.

References

Albe, Laurenz. 2026. “Schema in PostgreSQL Vs. Oracle: What’s the Difference? (Accessed: 2026-04-21).” https://www.cybertec-postgresql.com/en/schema-postgresql-oracle-difference/.

Amazon Web Services. 2026. “Amazon Rds Instance Types (Accessed 2026-06-13).” 2026. https://aws.amazon.com/rds/instance-types/.

Bellani, Eduardo. 2024. “How to Have Decoupled Systems without Setting Your Company on Fire.” https://ebellani.github.io/blog/2024/how-to-have-decoupled-systems-without-setting-your-company-on-fire/.

Brooker, Marc. 2015. “Exponential Backoff and Jitter (Accessed on 2024-09-22).” AWS Architecture Blog. https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/.

Codd, E. F. 1970. “A Relational Model of Data for Large Shared Data Banks.” Commun. Acm 13 (6): 377–87. https://doi.org/10.1145/362384.362685.

Date, C.J. 2003. An Introduction to Database Systems. 8th ed. USA: Addison-Wesley Longman Publishing Co., Inc.

Datta, Dibyendu. 2024. “Transactional Vs. Analytical Databases: How They Primarily Differ (Accessed: 2026-06-20).” May 2024. https://www.cdata.com/blog/transactional-vs-analytical-databases.

Gerogiannakis, Stelios. 2019. “Postgres Index Stats and Query Optimization (Accessed 2025-12-17).” https://sgerogia.github.io/Postgres-Index-And-Queries/.

Ghemawat, Sanjay, Robert Grandl, Srdjan Petrovic, Michael Whittaker, Parveen Patel, Ivan Posva, and Amin Vahdat. 2023. “Towards Modern Development of Cloud Applications.” In Proceedings of the 19th Workshop on Hot Topics in Operating Systems, 110–17. Hotos ’23. Providence, RI, USA: Association for Computing Machinery. https://doi.org/10.1145/3593856.3595909.

Group, PostgreSQL Global Development. n.d. “Monitoring Database Activity: Pg_Stat_All_Indexes View (Accessed: 2025-12-09).” PostgreSQL Global Development Group. https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW.

Inc., Visa. 2025. “Chairman and Ceo Message Accessed: 2026-03-19.” Visa Inc.Annual Report 2025. https://annualreport.visa.com/chairman-and-ceo-message/default.aspx.

Increase, Inc. 2025. “Transactions and Transfers (Accessed on 2025-12-04).” Online documentation. https://increase.com/documentation/transactions-transfers#transactions-and-transfers.

Koppel, Jimmy. 2023. “’Modules Matter Most’ for the Masses (Accessed on 2024-10-10).” pathsensitive blog. https://www.pathsensitive.com/2023/03/modules-matter-most-for-masses.html.

Kulkarni, Krishna, and Jan-Eike Michels. 2012. “Temporal Features in Sql:2011.” Sigmod Rec. 41 (3): 34–43. https://doi.org/10.1145/2380776.2380786.

Microsoft. 2024. “Temporal Tables.” Microsoft documentation. https://learn.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables.

Nubank. 2022. “Pix Breaks Record and Reaches 1 Billion Monthly Transactions (Accessed: 2026-03-19).” https://international.nubank.com.br/company/pix-breaks-record-and-reaches-1-billion-monthly-transactions/.

Oracle Corporation. 2026. Create Assertion. https://docs.oracle.com/en/database/oracle/oracle-database/26/sqlrf/create-assertion.html.

Pascal, Fabian. 2019. “Understanding Domains and Attributes (Accessed: 2026-05-30).” https://www.dbdebunk.com/2019/02/understanding-domains-and-attributes.html.

———. 2026. “What Meaning Means: Business Rules, Predicates, Constraints, and Semantic Consistency (Accessed 2026-03-19).” https://www.dbdebunk.com/2026/01/what-meaning-means-business-rules.html.

Paystand. 2024. “How Long Does a Wire Transfer Take?” 2024. https://www.paystand.com/blog/how-long-does-a-wire-transfer-take.

PostgreSQL Wiki Contributors. 2024. “Application Time Progress: Primary Keys and Unique Constraints.” PostgreSQL Wiki. 2024. https://wiki.postgresql.org/wiki/ApplicationTimeProgress#Primary_Keys_and_Unique_Constraints.

Samuel, Raz. 2024. “Understanding Hot Updates in Postgresql: A Benchmark Analysis.” 2024. https://www.razsamuel.com/understanding-hot-updates-in-postgresql-a-benchmark-analysis/.

Swart, Bennie. 2019. “Row Level Security.” Postgres Conference. Postgres Conference US. https://postgresconf.org/system/events/document/000/000/996/pgconf_us_2019.pdf.

The PostgreSQL Global Development Group. 2025. “Heap-Only Tuples (Hot).” The PostgreSQL Global Development Group. https://www.postgresql.org/docs/18/storage-hot.html.

———. 2026. D.2. Unsupported Features Accessed: 2026-03-19. https://www.postgresql.org/docs/current/unsupported-features-sql-standard.html.

Thomas, Shaun. 2018. “On Rocks and Sand.” 2018. https://www.enterprisedb.com/blog/rocks-and-sand.

Veen & Dave Pitts, Derk van. 2022. “Fighting Postgresql Write Amplification with Hot Updates.” 2022. https://www.adyen.com/knowledge-hub/postgresql-hot-updates.

White, Paul. 2015. “Indexed View Maintenance in Sql Server Execution Plans (Accessed: 2026-06-21).” https://www.sql.kiwi/2015/03/indexed-view-maintenance-in-execution-plans/.

Winand, Markus. n.d. “Paging through Results (Accessed: 2026-06-21).” https://use-the-index-luke.com/sql/partial-results/fetch-next-page.

Yourdon, Edward, and Larry L. Constantine. 1979. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. 2nd ed. Englewood Cliffs, NJ: Prentice-Hall.

https://nearform.com. n.d. “Temporal_Tables - Postgresql Temporal_Tables Extension in Pl/Pgsql, without the Need for External c Extension.” https://github.com/nearform/temporal_tables.

Complexity here is defined as the quantity of interacting parts of a whole ↩︎
A note on the code snippets: we will show code as we progress on the article, but the full code suite can be found on the [BROKEN LINK: blog/all-you-need-is-postgresql.pre-processed.org::#appendix-a-full-code-suite] for ease of copy. ↩︎
On oracle there are further complications. See (Albe 2026) ↩︎
For a refresh on what these kinds of balances are, see [BROKEN LINK: blog/all-you-need-is-postgresql.pre-processed.org::#the-setup] ↩︎
(which is the case for Postgres(The PostgreSQL Global Development Group 2026) but not for Oracle(Oracle Corporation 2026)) ↩︎
Such constraints are almost never created at the data level, exposing applications to the risk of failing audits and worse. ↩︎
Temporal tables can be used for several interesting features:
- Auditing all data changes and performing data forensics when necessary
- Reconstructing state of the data as of any time in the past
- Calculating trends over time
- Maintaining a slowly changing dimension for decision support applications
- Recovering from accidental data changes and application errors Auditing all data changes and performing data forensics when necessary (Microsoft 2024)
↩︎

Cloudflare's outage should not have happened, and they seem to be missing the point on how to avoid it in the future

2025-11-26T00:00:00Z

[BROKEN LINK: blog/google-cloud-s-outage-should-not-have-happened-and-they-seem-to-be-missing-the-point-on-how-to-avoid-it-in-the-future.pre-processed.org], another global IT outage happened (dèjá vu strikes again in our industry). This time at cloudflare(Prince 2025). Again, taking down large swaths of the internet with it(Booth 2025).

And yes, like my previous analysis of the GCP and CrowdStrike’s outages, this post critiques Cloudflare’s root cause analysis (RCA), which — despite providing a great overview of what happened — misses the real lesson.

Here’s the key section of their RCA:

Unfortunately, there were assumptions made in the past, that the list of columns returned by a query like this would only include the “default” database:

SELECT name, type FROM system.columns WHERE table = ‘http_requests_features’ order by name;

Note how the query does not filter for the database name. With us gradually rolling out the explicit grants to users of a given ClickHouse cluster, after the change at 11:05 the query above started returning “duplicates” of columns because those were for underlying tables stored in the r0 database.

This, unfortunately, was the type of query that was performed by the Bot Management feature file generation logic to construct each input “feature” for the file mentioned at the beginning of this section.

The query above would return a table of columns like the one displayed (simplified example):

However, as part of the additional permissions that were granted to the user, the response now contained all the metadata of the r0 schema effectively more than doubling the rows in the response ultimately affecting the number of rows (i.e. features) in the final file output.

A central database query didn’t have the right constraints to express business rules. Not only it missed the database name, but it clearly needs a distinct and a limit, since these seem to be crucial business rules.

So, a new underlying security work manifested the (unintended) potential already there in the query. Since this was by definition unintended, the application code didn’t expect that value to be what it was, and reacted poorly. This caused a crash loop across seemingly all of cloudflare’s core systems. This bug wasn’t caught during rollout because the faulty code path required data that was assumed to be impossible to be generated.

Sounds familiar? It should. Any senior engineer has seen this pattern before. This is classic database/application mismatch. With this in mind, let’s review how Cloudflare is planning to prevent this from happening again:

Hardening ingestion of Cloudflare-generated configuration files in the same way we would for user-generated input

Enabling more global kill switches for features

Eliminating the ability for core dumps or other error reports to overwhelm system resources

Reviewing failure modes for error conditions across all core proxy modules

These are all solid, reasonable steps. But here’s the problem: they already do most of this—and the outage happened anyway.

Why? Because they seem to mistake physical replication with not having a single point of failure. This mistakes the physical layer with the logical layer. One can have a logical single point of failure without having any physical one, which was the case in this situation.

I base my paragraph on their choice of abandoning PostgreSQL and adopting ClickHouse(Bocharov 2018). The whole post is a great overview on trying to process data fast, without a single line on how to guarantee its logical correctness/consistency in the face of changes.

They are treating a logical problem as if it was a physical problem

I’ll repeat the [BROKEN LINK: blog/google-cloud-s-outage-should-not-have-happened-and-they-seem-to-be-missing-the-point-on-how-to-avoid-it-in-the-future.pre-processed.org] I offered in my previous article on GCP’s outage:

The real cause

These kinds of outages stem from the uncontrolled interaction between application logic and database schema. You can’t reliably catch that with more tests or rollouts or flags. You prevent it by construction—through analytical design.

No nullable fields.
(as a corollary of 1) full normalization of the database ([BROKEN LINK: blog/the-principles-of-database-design-or-the-truth-is-out-there.pre-processed.org])
formally verified application code(Chapman et al. 2024)

Conclusion

FAANG-style companies are unlikely to adopt formal methods or relational rigor wholesale. But for their most critical systems, they should. It’s the only way to make failures like this impossible by design, rather than just less likely.

The internet would thank them. (Cloud users too—caveat emptor.)

References

Bocharov, Alex. 2018. “Http Analytics for 6m Requests per Second Using Clickhouse.” https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-clickhouse/.

Booth, Robert. 2025. “What Is Cloudflare — and Why Did Its Outage Take down so Many Websites?” https://www.theguardian.com/technology/2025/nov/18/what-is-cloudflare-and-why-did-its-outage-take-down-so-many-websites.

Chapman, Roderick, Claire Dross, Stuart Matthews, and Yannick Moy. 2024. “Co-Developing Programs and Their Proof of Correctness.” Commun. Acm 67 (3): 84–94. https://doi.org/10.1145/3624728.

Prince, Matthew. 2025. “Cloudflare Outage on November 18, 2025.” https://blog.cloudflare.com/18-november-2025-outage/.

Figure 1: The Cluny library was one of the richest and most important in France and Europe. In 1790 during the French Revolution, the abbey was sacked and mostly destroyed, with only a small part surviving

On dealing with GPT results, or, Pots, Kettles And Hallucinations

2025-10-18T00:00:00Z

Hallucinations in GPTs can lead to the dissemination of false information, creating harmful outcomes in applications of critical decision making or leading to mistrust in AI. In a viral instance, The New York Times published an article about a lawyer who used ChatGPT to produce case citations without realizing they were fictional, or hallucinated. This incident highlights the danger of hallucinations in LLM-based queries; often the hallucinations are subtle and go easily unnoticed. Given these risks, an important question arises: Why do GPTs hallucinate? (Waldo and Boussard 2024)

Given the above, how to safely use the results of GPTs? As (Waldo and Boussard 2024) put it, a GPT generates the most common response from its training corpus, reflecting the current linguistic consensus. Where there is such consensus, GPTs appear accurate; where there is controversy or little data, hallucination follows.

Therein lies the crux of the matter: most people would see the current ideas represented in the LLM training corpus as representing truth, since they are the most popular (presumably) ideas around. So, someone would need to already have an apprehension of actual truth to be able to trust the output of the LLM.

An interesting turn is that one can take the (Waldo and Boussard 2024) itself as an example. Here is what it says about Epistemic Trust:

We tend to forget how recent the current mechanisms are for establishing trust in a claim. The notion that science is an activity based on experience and experiment can be traced back to Francis Bacon in the 17th century; the idea that we can use logic and mathematics to derive new knowledge from base principles can be traced to about the same period to René Descartes. This approach of using logic and experiment is a hallmark of the Renaissance. Prior to that time, trust was established by reference to ancient authorities (such as Aristotle or Plato) or from religion.

What has emerged over the past number of centuries is the set of practices that are lumped together as science, which has as its gold standard the process of experimentation, publication, and peer review. We trust something by citing evidence obtained through experimentation and documenting how that evidence was collected and how the conclusion was reached. Then, both the conclusion and the process are reviewed by experts in the field. Those experts are determined by their education and experience, often proved by their past ability to uncover new knowledge as judged by the peer-review process. ¹

The first paragraph is an example of something that is clearly part of the current intellectual landscape, and very likely what would be generated by a LLM. As a matter of fact, here is what ChatGPT-5 replied when fed this text:

Your paragraph is mostly correct in its broad strokes…

Given that I have some knowledge in this matter, I can tell the paragraph is wrong:

Bacon did not establish science as an activity of experience and experiment. What he did was to deny the validity of form, finality and ultimately metaphysics in the universe. Given that his work is a work arguing for a form(sense perception), finality(man) and metaphysics (sense perception as the only ground for truth), he is a self refuting ideologue.
Descartes did something similar, denying the validity of anything that was not quantity (including sense perception, ironically). His is a self refuting position for the same reason.

Here is what the educated man thought science was before Bacon and Descartes:

The method is the path that intelligence must follow for the acquisition of science. It has 3 elements: a starting point, a process and an end.

The starting point cannot be universal doubt, but must rest in immediately evident truths(necessary regarding its rational part, contingent regarding its experimental part).

The process is the method properly speaking, being analytical or synthetic, in accordance to its direction — from/to the objects that have more/less comprehension.

The end is science, which is a system of correct knowledge, relative to the cause of beings and ultimately deduced through demonstration. Such science can be rational or experimental, and is structured in a dependency hierarchy. ² (Sinibaldi 2021)

Conclusion and advice

GPT queries are useful only when you can verify them. When that is possible, GPTs become a viable exploration and templating system.

So, the practical advice boils down to: don’t rely on it in areas you are not well versed in already.

Given how this advice applies to (Waldo and Boussard 2024) itself — where the authors ventured in a branch of knowledge that they didn’t seem to hold expertise besides the current popular science milieu — the follow image seems appropos here.

Figure 1: Charles H. Bennett’s coloured engraving from Shadow and Substance (1860), a series based on popular sayings. In this case, a coal-man and chimney sweep stop to argue in the street in illustration of “The pot calling the kettle black”. A street light throws the shadow of the kitchen implements on the wall behind them.

References

Sinibaldi, Dom Thiago. 2021. Compêndio Elementos de Filosofia (4 Vols.). 5ª ed. Florianópolis, SC, Brazil: Instituto Santo Agostinho. https://loja.institutosantoagostinho.org/compendio-elementos-de-filosofia-dom-thiago-sinibaldi.

Waldo, Jim, and Soline Boussard. 2024. “Gpts and Hallucination.” Commun. Acm 68 (1): 40–45. https://doi.org/10.1145/3703757.

Have you noticed that the second paragraph supports what the ancients did, in refeering to Plato and Aristotle? ↩︎
From the portuguese, translated by this author. ↩︎

What is mathematics? A classification based on universals

2025-08-17T00:00:00Z

I find that it is hard for me to motivate myself to learn a subject that one cannot define. So I made an effort to define mathematics, and the best source I have ever found was (Franklin 2014).

To sum up my views on the topic: at the core of philosophical inquiry, one finds a deep division into 2 opposites as their regard to the universals, realism and nominalism(and its kantian variant, conceptualism)(De Wulf 1911). Taking that into consideration and (Franklin 2014), Here is a taxonomy of definitions for what is mathematics:

Realism

Platonism: Knowledge of another dimension
Aristotelianism: Knowledge of instantiation of universals and structure (parts to whole)

Nominalism

Language: A Language of science
Logicism: A process to guide inferences
Formalism: The manipulation of uninterpreted symbols

References

De Wulf, Maurice. 1911. “Nominalism, Realism, Conceptualism.” The Catholic Encyclopedia, Vol 11. https://www.newadvent.org/cathen/11090c.htm.

Franklin, James. 2014. An Aristotelian Realist Philosophy of Mathematics: Mathematics as the Science of Quantity and Structure. Palgrave Macmillan.

Figure 1: Venerabilis nominalium incaeptor (the venerable fouder of nominalism)

Google Cloud's outage should not have happened, and they seem to be missing the point on how to avoid it in the future

2025-06-14T00:00:00Z

[BROKEN LINK: blog/analyzing-crowdstrike-s-root-cause-analysis-or-on-missing-the-point-about-quality.pre-processed.org], this time at Google Cloud Platform (team 2025), taking down with it large swaths of the internet (Zeff 2025). Like my previous analysis of the CrowdStrike outage, this post critiques GCP’s root cause analysis (RCA), which—despite detailed engineering steps—misses the real lesson.

Here’s the key section of their RCA:

Google and Google Cloud APIs are served through our Google API management and control planes. Distributed regionally, these management and control planes are responsible for ensuring each API request that comes in is authorized, has the policy and appropriate checks (like quota) to meet their endpoints. The core binary that is part of this policy check system is known as Service Control. Service Control is a regional service that has a regional datastore that it reads quota and policy information from. This datastore metadata gets replicated almost instantly globally to manage quota policies for Google Cloud and our customers.

On May 29, 2025, a new feature was added to Service Control for additional quota policy checks. This code change and binary release went through our region by region rollout, but the code path that failed was never exercised during this rollout due to needing a policy change that would trigger the code. As a safety precaution, this code change came with a red-button to turn off that particular policy serving path. The issue with this change was that it did not have appropriate error handling nor was it feature flag protected. Without the appropriate error handling, the null pointer caused the binary to crash. Feature flags are used to gradually enable the feature region by region per project, starting with internal projects, to enable us to catch issues. If this had been flag protected, the issue would have been caught in staging.

On June 12, 2025 at ~10:45am PDT, a policy change was inserted into the regional Spanner tables that Service Control uses for policies. Given the global nature of quota management, this metadata was replicated globally within seconds. This policy data contained unintended blank fields. Service Control, then regionally exercised quota checks on policies in each regional datastore. This pulled in blank fields for this respective policy change and exercised the code path that hit the null pointer causing the binaries to go into a crash loop. This occurred globally given each regional deployment. (team 2025)

A central database had a nullable field. A new policy change injected a blank value into this field. The application code didn’t expect that value to be null, which caused a crash loop across all regions. The bug wasn’t caught during rollout because the faulty code path required a policy trigger that never occurred in staging

Sound familiar? It should. Any senior engineer has seen this pattern before. This is classic database/application mismatch and the age-old curse of NULL(McGoveran 1993). With this in mind, let’s review how GCP is planning to prevent this from happening again:

1. We will modularize Service Control's architecture, so the
   functionality is isolated and fails open. Thus, if a corresponding
   check fails, Service Control can still serve API requests.
2. We will audit all systems that consume globally replicated
   data. Regardless of the business need for near instantaneous
   consistency of the data globally (i.e. quota management settings are
   global), data replication needs to be propagated incrementally with
   sufficient time to validate and detect issues.
3. We will enforce all changes to critical binaries to be feature flag
   protected and disabled by default.
4. We will improve our static analysis and testing practices to
   correctly handle errors and if need be fail open.
5. We will audit and ensure our systems employ randomized exponential
   backoff.
6. We will improve our external communications, both automated and
   human, so our customers get the information they need asap to react
   to issues, manage their systems and help their customers.
7. We'll ensure our monitoring and communication infrastructure remains
   operational to serve customers even when Google Cloud and our primary
   monitoring products are down, ensuring business continuity.

These are all solid, reasonable steps. But here’s the problem: they already do most of this—and the outage happened anyway.

Why? Because of this admission, buried in their own RCA:

…this policy data contained unintended blank fields…

They are treating a design flaw as if it were a testing failure.

The real cause

No nullable fiels.
(as a cororally of 1) full normalization of the database ([BROKEN LINK: blog/the-principles-of-database-design-or-the-truth-is-out-there.pre-processed.org])
formally verified application code(Chapman et al. 2024)

Conclusion

The internet would thank them. (Cloud users too—caveat emptor.)

References

Chapman, Roderick, Claire Dross, Stuart Matthews, and Yannick Moy. 2024. “Co-Developing Programs and Their Proof of Correctness.” Commun. Acm 67 (3): 84–94. https://doi.org/10.1145/3624728.

McGoveran, David. 1993. “Nothing from Nothing Series.” Database Program. Des., 33–41.

Zeff, Maxwell. 2025. “Google Cloud Outage Brings down a Lot of the Internet.” https://techcrunch.com/2025/06/12/google-cloud-outage-brings-down-a-lot-of-the-internet/.

team, GCP. 2025. “Multiple Gcp Products Are Experiencing Service Issues Incident Began at 2025-06-12 10:51 and Ended at 2025-06-12 18:18 (Accessed on 2025-06-14).” https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW.

Figure 1: Boulogne-sur-Mer cathedral: destroyed by the Revolution. The cathedral in 1570, drawn by Camille Enlart (1862-1927)

The principles of database design, or, the Truth is out there

2025-05-17T00:00:00Z

Every software project needs to represent the reality of the business he is embedded in. The way we can represent reality as limited rational beings is through propositions, i.e, declarative statements that affirm or deny something about reality. When a collection of such propositions is stored in a computer system, we call it a database.

Such database needs to be designed to properly reflect reality. This can’t be automated, since the semantics of the situation need to be encoded in a way that can be processed by a computer. Such then is the goal of database design: to encode propositions in such a way that can properly be processed by a database management system (DBMS).

At this point, a regular software developer comes to a stall. Since there is scarcely any formal training in database design (or formal logic) in his education, he tends to fall back haphazardly on ad-hoc methods, with severe consequences (update anomalies and data inconsitencies with huge potential downsides).

If you are such developer, you need to understand the underlying principles of database design. Think about it, if you don’t have principles of design, you are not doing engineering, are you?

Here is a list of design principles to follow for formal database design(McGoveran 2012, 2015)(Pascal 2016):

Principle of Orthogonal Design (POOD): Base relations are independent;
Principle of Representational Parsimony (PORP): There are no superfluous base relations;
Principle of Expressive Completeness (POEC): All meaningful relations are derivable from the base relations.
Principle of Full Normalization (POFN) : Every base relation should be in its highest normal form (3, 5 or 6th normal form). Thus eliminating redundancy and preventing anomalies by ensuring that each relation is free from undesirable characteristics like partial, transitive, or join dependencies.
The Information Principle (TIP) : All information in the database is represented explicitly and in exactly one way — by attribute values drawn from domains in relations.
Principle of Logical Independence (PLI) : Application programs and terminal activities remain logically unimpaired when information preserving changes of any kind that theoretically permit unimpairment are made to the base relations.

To these I’d like to introduce a new principle, an innovation I hope to develop in future work:

Principle of Essential Denotation (PED): A relation should be identified by a natural key that reflects the entity’s essential, domain-defined identity — not by arbitrary or surrogate values.

The following pseudo-SQL shows the contrast between improper and proper denotation:

-- usage of surrogate keys
create table citizen (
  id uuid primary key,
  national_id text,
  full_name text);

Code Snippet 1: Illustration of not using PED with SQL

This usage has some problems, the worst of it is the disconnection between database structure and domain semantics. Here is a rework that preserves such connection:

create domain national_id as text check (...);

create table citizen (
  national_id national_id primary key,
  full_name text);

Code Snippet 2: Illustration of using PED with SQL

Conclusion

Databases are representations of reality, and as such, they are foundational to any serious information system. Poor design leads to semantic confusion and technical instability—with consequences that can be costly and far-reaching. Good design demands rigor, discipline, and a firm grasp of foundational principles.

To put it simply: if you’re in the business of information, you need to know how to build structures that tell the truth that is out there.

References

Blakemore, Erin. 2019. “The Notre-Dame Cathedral Was Nearly Destroyed by French Revolutionary Mobs (Accessed on 2025-05-18).” https://web.archive.org/web/20190607211856/https://www.history.com/news/notre-dame-fire-french-revolution.

McGoveran, David. 2012. “Updating a Database.” Alternative Technologies Blog. http://w.alternativetech.com/publications/View%20Updating%206-12-12.pdf.

———. 2015. “Can All Relations Be Updated? (or Can Any Relation Be Updated?) Logic for Serious Database Folks Series.” Alternative Technologies Blog. https://www.alternativetech.com/publications/Logic%20for%20DB%20Folks%20Series%20XX%20-%20Updating%20Relations.pdf.

Pascal, Fabian. 2016. “The Principle of Orthogonal Database Design Part I.” https://www.dbdebunk.com/2016/09/the-principle-of-orthogonal-database.html.

Figure 1: But revolutionary Parisians had had enough of its royal resonance. The cathedral’s west facade featured 28 statues that portrayed the biblical Kings of Judah. In fall 1793, the new government ordered workers to remove them. They didn’t portray French kings, but no matter: The 500-year-old statues combined monarchy and religion, and they were brought to the cathedral’s square and decapitated. Twenty-one of the heads were only recovered in 1977, when workers found them behind a wall in an old Parisian mansion.(Blakemore 2019)

Theory in practice: Why Treating Metadata as Relations Pays Off

2025-04-14T00:00:00Z

Underpinning relational databases you find a very powerful principle: all your information should be represented as attributes drawn from domains in relations(Pascal 2020). This is Codd’s Information Principle #1. This principle isn’t just fluffy theory: it can lead to very concrete wins in how we design, query, and maintain systems.¹

A practical case: Dependencies for Security Policies

This is clearly a metadata question: Which other database objects does this view depend on? In many environments, answering that might involve using external tools or writing scripts in another language. But in PostgreSQL, you can answer it with a simple query because PostgreSQL respects Codd’s principle and exposes metadata as part of its relational structure.

select distinct
  source_schema.nspname as source_object_schema_name,
  source_object.relname as source_object_name,
  dependent_schema.nspname as dependent_object_schema_name,
  dependent.relname as dependent_object_name,
  dependent.relkind as dependent_object_type
  from
    pg_rewrite rw
    join pg_class     source_object      on rw.ev_class    = source_object.oid
    join pg_depend    dep              on dep.objid      = rw.oid
    join pg_class     dependent        on dep.refobjid   = dependent.oid
    join pg_namespace source_schema    on source_schema.oid = source_object.relnamespace
    join pg_namespace dependent_schema on dependent_schema.oid = dependent.relnamespace
 where
     (dependent_schema.nspname <> source_schema.nspname or dependent.relname <> source_object.relname)
     and source_object.relname = 'MY_VIEW' and source_schema.nspname = 'MY_SCHEMA';

Code Snippet 1: Retrieves all objects (tables, views, etc.) that MY_SCHEMA.MY_VIEW depends on — across schemas and object types

Conclusion

When your system represents metadata relationally, you can reason about it with the same tools you use for business data. No context-switching, no ETL jobs, no external tools. Just your relationally inspired SQL.

This aligns with the foundational ideas behind relational databases and shows that following sound principles can yield practical advantages.

References

Pascal, Fabian. 2020. “Understanding Codd’s 12 Rules for Rdbms (Accessed on 2025-04-14).” https://www.dbdebunk.com/2020/10/understanding-codds-12-rules-for-rdbms.html.

Figure 1: The Cathedral of the Archangel Michael in Bronnitsy underwent a relatively mild transformation: It was used as a state book archive - but the “book of books,” the Bible, surely couldn’t be found there.

Recently I had a conversation on linkedin: https://www.linkedin.com/feed/update/urn:li:ugcPost:7316402764975075328?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7316402764975075328%2C7316457084038930432%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287316457084038930432%2Curn%3Ali%3AugcPost%3A7316402764975075328%29 ↩︎

How to Replace LeetCode with Something That Actually Works

2025-04-04T00:00:00Z

Recently there has been an interest in cheating(?) leetcode style interviews(Yang 2025). These articles highlight a longstanding issue in tech recruiting: puzzle-style assessments have little to no correlation with actual job performance(Konnikova 2013; McAllister 2013), and leetcode is nothing but algorithmic puzzles. This makes them a poor predictor of job performance. What leetcode does predict seems to be success at leetcode style interviews(Mroczka 2024). Go figure.

If you are in power to stop doing these silly things and reach for something with actual evidence of working, here is a blueprint for performing a structured interview with a focus on programmers, but that can be adapted for other positions quite easily.

A core part of a structured interview is to determine the competencies to be assessed by the interview(of Personnel Management 2008). According to (Hogan and Warrenfeltz 2003), the skills and behaviors found in virtually every organizational competency model fall into one of four major domains, and that they form a natural, overlapping developmental sequence, with the latter skills (e.g., Leadership Skills) depending on the appropriate development of the earlier skills (e.g., Intrapersonal Skills).

Intrapersonal

These skills develop early in childhood and have important consequences for career development in adulthood. Core components include core-self esteem, resiliency, and self-control. Intrapersonal skills form the foundation on which careers develop.

Questions

Can you describe a situation in your life where your capacity of planning made a difference?
Can you describe a situation in your life where your capacity for discipline made a difference?
Can you describe a situation in your life where your capacity for flexibility in thinking made a difference?

Answers

1: Candidate demonstrated very little conscientiousness and emotional stability in the answers. Apathetic, unstable, resented.
5: Candidate demonstrated a lot of conscientiousness. Resiliency, intelligent risk taking, disciplined effort.

Interpersonal

These skills concern building and sustaining relationships. Interpersonal skills can be described in terms of three components:

an ability to put oneself in the position of another person,
an ability to accurately perceive and anticipate other’s expectations, and
an ability to incorporate information about the other person’s expectations into subsequent behavior.

Questions

Can you describe a situation in your life where your capacity for building relationships with others made a difference?
Can you describe a situation in your life where your capacity for teamwork made a difference?
Can you describe a situation in your life where your capacity for communicating made a difference?

Answers

1: Candidate demonstrated very little capacity for working with others. Imprecise language, bad intonation, weird social cues.
5: Candidate demonstrated a lot of capacity to integrate and to work with others. Lots of agreeable, extroverted behaviors.

Technical

These skills differ from Intrapersonal and Interpersonal skills in that they are

the last to develop,
the easiest to teach,
the most cognitive, and
the least dependent upon dealing with other people.

Technical skills involve comparing, compiling, innovating, computing, analyzing, coordinating, synthesizing, and so on.

Questions

Can you describe your technical progress in your career?
What’s your favorite programming language and why do you like it the most?
Can you describe how you make technical judgements when facing scarce resources (time, etc)?
Can you describe what is a good software development environment?

Answers

1: Candidate demonstrated very little awareness of the Computer Science field. Only the obvious knowledge, and very shallow at that.
5: Candidate demonstrated amazing grasp of the field, quoting different areas and integrating them into a coherent whole.

Business

These skills can be understood in terms of components that depend upon intrapersonal, interpersonal, and technical skills. The point here is to understand if the person is capable of using his whole tool set to generate value for others.

For a leader these entail an ability to recruit talented people to join the team. Second, one must be able to retain talent once it has been recruited. Third, one must be able to motivate a team. Fourth, effective leaders are able to develop and promote a vision for the team. Finally, leadership skill involves being persistent and hard to discourage.

For a follower, the persistance component is shared, alongside initiative.

Questions

Can you describe a situation where you generated value for others?
Can you describe a situation where your initiative made a difference?
Can you describe how your technical knowledge might help a business like ours?
Can you describe what is a good software development team?
Can you describe what is your ideal technical vision?

Answers

1: Candidate demonstrated very little capacity for integrating his knowledge. Confused technical vision, murky connections.
5: Candidate demonstrated a great grasp on how to use his whole knowledge to help the business and his team.

Conclusion:

Tech hiring is long overdue for an evidence-based overhaul. Structured interviews rooted in validated competencies not only predict performance better — they respect candidates’ time and intelligence. If you’re hiring engineers, skip the puzzles and build a process that actually works.

Figure 1: Andronikov Monastery of the Savior is a well-preserved monastery from the late Middle Ages. The communists turned it into one of the first concentration camps for political prisoners

References

Hogan, Robert, and Rodney Warrenfeltz. 2003. “Educating the Modern Manager.” Academy of Management Learning & Education 2 (1): 74–84.

Konnikova, Maria. 2013. “Why Brainteasers Don’t Belong in Job Interviews (Accessed on 2025-04-04).” https://www.newyorker.com/tech/annals-of-technology/why-brainteasers-dont-belong-in-job-interviews.

McAllister, Neil. 2013. “Google Staffing Boss: Our Old Hiring Procedures Were ’worthless’ (Accessed on 2025-04-04).” https://www.theregister.com/2013/06/20/google_hiring_procedures/.

Mroczka, Mike. 2024. “How Well Do Leetcode Ratings Predict Interview Performance? Here’s the Data. (Accessed on 2025-04-04).” https://interviewing.io/blog/how-well-do-leetcode-ratings-predict-interview-performance.

Personnel Management, U.S. Office of. 2008. “Structured Interviews: A Practical Guide.”

Yang, Angela. 2025. “Kicked out of Columbia, This Student Doesn’t Plan to Stop Trolling Big Tech with Ai (Accessed on 2025-04-04).” nbcnews. https://www.nbcnews.com/tech/tech-news/columbia-university-student-trolls-big-tech-ai-tool-job-applications-rcna198454.

Queries when you have a postgresql based system

2025-03-24T00:00:00Z

Are you managing/developing a PostgreSQL based application? Here are some scripts that might make your life easier dealing with your installation:

select
  schema_name,
  relname,
  pg_size_pretty(table_size)
  from
    (select
       pg_catalog.pg_namespace.nspname as schema_name,
       relname,
       pg_total_relation_size(pg_catalog.pg_class.oid) as table_size
       from pg_catalog.pg_class
            join pg_catalog.pg_namespace on relnamespace = pg_catalog.pg_namespace.oid
    ) t
 where schema_name not like 'pg_%'
 order by table_size desc
 limit 5;

Code Snippet 1: Check the 5 largests tables (courtesy of Supabase's dashboard)

select * from cron.job_run_details order by start_time desc limit 5;

Code Snippet 2: Check the current running cron jobs

select act.query,
       act.datname,
       act.query_start,
       nspname as schema_name,
       relname as object_name,
       l.pid
  from pg_locks l
       join pg_class c on (relation = c.oid)
       join pg_namespace nsp on (c.relnamespace = nsp.oid)
       join pg_stat_activity act on (l.pid = act.pid)
 where l.pid in
       (select pid
          from pg_stat_activity
         where datname = current_database()
           and query != current_query())
 order by pid;

Code Snippet 3: See what is being locked by what (pg_terminate can unlock things)

How to have decoupled systems without setting your company on fire

2024-12-17T00:00:00Z

Have you heard that having decoupled systems is paramount to dealing with complexity at the heart of software?

Have you also seen companies waste piles of cash and lots of developer time trying to build decoupled systems?

This article might be of your interest, since my goal is to teach you how to build decoupled systems cheaply and using technology that is battle tested and that will keep you in control. How? By

See the problems of the current widespread solution to coupling: microservices;
See how to implement decoupled systems using a SQL DBMS;
Visit a bit of the underlying theory about coupling/modularity/views in light of what was presented.

A summary of the comparison: Microservices vs SQL DBMS

Microservices

Poor performance with serialization and networking
Correctness problems over versioning in a distributed system
Hard to manage multiple binaries and e2e testing
Dangerous to change APIs
Slow development because of lack of atomicity of changes

(Ghemawat et al. 2023)

SQL DBMS

Great performance with data colocation
Correctness by default
Single system, easy to test e2e
Change is made safe by constraints
ACID baby

The core point

this rule means: We have a module N which uses some module M, but only through its type (interface) A. M can be replaced by any other module with the same type, and N will continue to work. That’s modularity. (Koppel 2023)

Or, in non-alien language: It means that the relation between interfaces and implementations is many-to-many. That means that modularity is a logical property that can be implemented in many ways.

The canonical way of doing it in the relational model is through views.

So what about views?

You can have many views (interfaces) over the same base tables (implementations). (many to one)

The same view can have multiple ways of being deduced from the base tables. (one to many)

This implements modularity, as defined in the previous section

The original view (pun intended) about views

In contrast, the problems treated here are those of data independence-the independence of application programs and terminal activities from growth in data types and changes in data representation

…

Activities of users at terminals and … application programs should remain unaffected when the internal representation of data is changed and even when some aspects of the external representation are changed.

(Codd 1970)

It used to be called logical data independence. It can also be called de-coupling.

Figure 1: The Church of Ulrich, over 1000 years old, was bombed in 1945 by the americans, but survived. In 1956, it was destroyed by the communists to create the new city center based on communist architecture.

References

Codd, E. F. 1970. “A Relational Model of Data for Large Shared Data Banks.” Commun. Acm 13 (6): 377–87. https://doi.org/10.1145/362384.362685.

Koppel, Jimmy. 2023. “’Modules Matter Most’ for the Masses (Accessed on 2024-10-10).” pathsensitive blog. https://www.pathsensitive.com/2023/03/modules-matter-most-for-masses.html.

How to unlock motivation for high performance in your team

2024-10-23T00:00:00Z

As an engineering manager(EM), one of your core tasks is to build and maintain a team of high performance. To accomplish this, it should be obvious that motivation is a key factor:

Why do followers join some teams but not others? How do you get followers to exhibit enough of the critical behaviors needed for the team to succeed? And why are some leaders capable of getting followers to go above and beyond the call of duty? The ability to motivate others is a fundamental leadership skill and has strong connections to building cohesive, goal-oriented teams and getting results through others. The importance of follower motivation is suggested in findings that most people believe they could give as much as 15 percent or 20 percent more effort at work than they now do with no one, including their own bosses, recognizing any difference. Perhaps even more startling, these workers also believed they could give 15 percent or 20 percent less effort with no one noticing any difference. Moreover, variation in work output varies significantly across leaders and followers. The top 15 percent of workers in any particular job may produce 20 to 50 percent more output than the average worker, depending on the complexity of the job. Put another way, the best computer programmers or salesclerks might write up to 50 percent more programs or process 50 percent more customer orders. (CURPHY et al. 2018)

Let’s assume that you are convinced that having a motivated team is key for your success as an EM. Now comes the question, how? Everyone and their dog has advice on this, mostly about your interactions with your followers. This article will focus on a different angle: the advice is to you about you, or more specifically, about your vision.

Why vision?

Followers expect leaders to provide a sense of mission and a hopeful view of the future and to explain why they are doing what they are doing and why it matters. (Warrenfeltz and Kellett 2016)

Now, how do you develop a vision? Since action follows from essence, we should understand what is the essence of a man. For this context, what matters is that man is a creature in tension between his contingent situation and the contemplation of God, the Eternal transcendence.

The way man deals with this tension sucessfully is with a story. This story is what connects his present to the vanishing point we call the future. (Noica, Blyth, and Stoiciu 2009)

Since it is likely that the vast majority of people you will encounter as followers have no such story, they will be inclined to follow yours as long as you present it clearly and be able to connect it to the company’s goals.

Summing it up: clarify to yourself and to others what is your story and how it connects to the current situation. There are specific tools available if you want help crafting your story, such as (Booker 2004).

Figure 1: Pontifical High Mass in the ruins of St Mary’s Cathedral, Nagasaki, Japan. December 7th, 1949 - (5 years after the atom bomb).

References

Booker, C. 2004. The Seven Basic Plots: Why We Tell Stories. The Seven Basic Plots: Why We Tell Stories. Continuum.

CURPHY, G.G., R.L. Hughes, R.C. Ginnett, and G.J. Curphy. 2018. Ise Leadership: Enhancing the Lessons of Experience. McGraw-Hill Education.

Noica, C., A.I. Blyth, and F. Stoiciu. 2009. Six Maladies of the Contemporary Spirit. 20 Romanian Writers Series. University of Plymouth Press.

Warrenfeltz, R., and T. Kellett. 2016. Coaching the Dark Side of Personality: High Impact Strategies to Build a Winning Leadership Reputation. Hogan Assessment Systems, Incorporated.

A simple way to deal with the principal threat to scalability

2024-09-20T00:00:00Z

If you have a distributed system one of the main worries you probably have is scalability. Well, what is the principal threat to scalability in such systems is the conflict between transactions that are used to guarantee correct results in concurrent operations.

Such conflicts are dealt with by concurrency control, either pessimistically via something like exclusive resource lock or optimistically via something like serializable snapshot isolation.

Let me illustrate the threat with from the pessimistic point of view:

Access to resources guarded by an exclusive lock is serialized—only one thread at a time may access it. Of course, we use locks for good reasons, such as preventing data corruption, but this safety comes at a price. Persistent contention for a lock limits scalability.

The principal threat to scalability in concurrent applications is the exclusive resource lock.

Two factors influence the likelihood of contention for a lock:

how often that lock is requested and

how long it is held once acquired.

(Goetz 2006)

The trick that I’m going to present addresses point 1, how often the lock is requested. Just to be clear, the same trick applies to optimistic concurrency control (OCC):

While OCC is guaranteed to make progress, it can still perform quite poorly under high contention. The simplest of these contention cases is when a whole lot of clients start at the same time, and try to update the same database row. With one client guaranteed to succeed every round, the time to complete all the updates grows linearly with contention. (Brooker 2015)

So, what is the trick? A combination of a capped exponential backoff with jittering in order to avoid synchronization of the retries of several clients. “Oh, it can’t be that simple” you say. Hear the expert out:

After 8 years, this solution continues to serve as a pillar for how Amazon builds remote client libraries for resilient systems.(Brooker 2015)

You can check the article above for an in-depth overview. If you are curious as to what a real version looks like, below I added the code that I contributed to Omnigres to implement this for automatic transaction retries(Bellani 2024).

static List *backoff_values;
static int32 retry_attempts = 0;
static int64 cap_sleep_microsecs = 10000;
static int64 base_sleep_microsecs = 1;

/**
 * The backoff should increase with each attempt.
 */
static int64 get_backoff(int64 cap, int64 base, int32 attempt) {
  int exp = Min(attempt, 30); // caps the exponent to avoid overflowing,
                              // as the user can control the # of
                              // attempts.
  return Min(cap, base * (1 << exp));
}

/**
 * Get the random jitter to avoid contention in the backoff. Uses the
 * process seed initialized in `InitProcessGlobals`.
 */
static float8 get_jitter() {
#if PG_MAJORVERSION_NUM > 14
  return pg_prng_double(&pg_global_prng_state);
#else
  return rand() / (RAND_MAX + 1.0);
#endif
}

/**
 * Implements the backoff + fitter approach
 * https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/
 */
static int64 backoff_jitter(int64 cap, int64 base, int32 attempt) {
  int64 ret = (int64)(get_jitter() * get_backoff(cap, base, attempt));
  return (ret > 0 ? ret : 1);
}

/**
 * Turns the value into something that can be consumed by
 * `pg_sleep`. The literal comes copied from there, to ensure the same
 * ratio.
 */
static float8 to_secs(int64 secs) { return (float8)secs / 1000000.0; }

Figure 1: The Benedictine Abbey on Monte Cassino, before and after being bombed by Allied forces, February 15 1944

References

Bellani, Eduardo. 2024. “Problem: Retries Can Perform Poorly under High Contention.” Github. https://github.com/omnigres/omnigres/commit/b9798409f007a6941dc6ad7ef2bccc6ac5cc7ba8.

Brooker, Marc. 2015. “Exponential Backoff and Jitter (Accessed on 2024-09-22).” AWS Architecture Blog. https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/.

Goetz, B. 2006. Java Concurrency in Practice. Addison-Wesley.

Debunking Event Sourcing

2024-08-23T00:00:00Z

Are you looking into event sourcing? I hope this article gives you enough information for you to properly contrast it with what I consider an overall better alternative: temporal tables.

The context: my last article ([BROKEN LINK: blog/are-you-considering-event-sourcing-think-again.pre-processed.org]) has produced some heated responses. One of the responders published an article (Dear Temporal Table Developers ❤) explaining

.. why temporal tables are … an inferior choice, especially for systems that require scalability, flexibility, and resilience in an ever-changing world.

Since the published reply contains an amalgamation of common positions on this matter, I want to use it as an opportunity to create a reference for myself and others in the future when debating this topic. Therefore, I’ll go topic by topic, linking to the appropriate place

Temporal Tables Aren’t True History

Events (allow) you to understand both the “what” and the “why” in a meaningful way.

Here the author is referring to the name of the event that should map to an use-case, and claiming that this is impossible with the relational model.

This is a bogus claim. If such data is demanded by your business rules, there is no reason why it can’t be expressed as part of a table. Here is an example:

{
  "name": "reservation-bought",
  "reservation-id": 1,
  "user-id": 33,
  "seat-id": 100,
  "venue-id: 12,
}

In a SQL version, all you need is to add the intent as a desired attribute.

create table reservation (
  user_name references user (name),
  seat int,
  venue string,
  intent text,
  CHECK (intent in ('buy', 'rent'))

Temporal Tables Impose Rigid Structure

This seems to be the main point of the article. So I’ll break it down in parts and index my replies below:

One of the biggest pitfalls of temporal tables is the inherent rigidity of the relational model.

As your application grows and evolves, so do your requirements, and changing a temporal table schema can become a significant burden.

Event Sourcing lets you evolve your system naturally. Each new feature or behavior can be introduced as a new event type, without the need to retroactively change the structure of your past data.

This point seems to imply ignorance of what the relational model (RM) is. The RM is a logical model based on set theory and predicate logic. One of the major points of the RM is to allow developers the flexibility to choose access paths after database design.
Changing the schema of a temporal database can potentially be serious and delicate work, since it might involve changing what you claimed were your past beliefs. This is an universal point.
Given the previous point, versioning in an event sourced system can be at least as hard as versioning any other. As one of the leaders of the ES/CQRS community puts it:

Over the years, I have met many developers who run into issues dealing with versioning, particularly in Event Sourced systems. This seems odd to me. As we will discuss, Event Sourced systems are in fact easier to version than structural data in most instances, as long as you know the patterns for how to version, where they apply, and the trade-offs between the options. dealing with versioning, particularly in Event Sourced systems. (Young 2017)

In fact, I’ll claim that managing the evolution of a temporal structure in event sourced systems is harder. I’m not alone in this assessment:

Data conversion in event sourced systems introduces new challenges, because of the relative novelty of the event sourcing architectural pattern, because of the lack of standardized tools for data conversion, and because of the large amount of data that is stored in typical event stores.(Overeem, Spoor, and Jansen 2017)

Temporal Tables Aren’t Built for Distributed Systems

.. temporal tables simply don’t cut it. They are designed with a single-node, relational mindset, which makes them ill-suited for large-scale, distributed architectures.

I think the author here is confusing a logical approach, temporal tables, with an implementation in a DBMS, such as PostgreSQL or SQL Server. One can certainly scale a modern DBMS to impressive results(Justin Kwan 2022).

Complex Queries and Performance Overhead

With CQRS, you avoid this mess entirely. Instead of bloating your read models with historical data, you can create dedicated read projections that are optimized for the specific queries you need. Event-driven architectures naturally lend themselves to this approach, allowing you to create purpose-built views without overloading your database.

The author seems to be impliying that creating projections are in any way better than creating queries. This is the opposite of reality, because:

You will pay the cost of maintaining each read projection(Kiehl 2019) as you would with a view or a snapshot
SQL is a DSL specifically designed for querying
CQRS itself adds risky complexity(Fowler 2011). A very risky kind of complexity indeed: consistency problems.

Temporal Tables Create Monoliths, Not Microservices

This is confusing logical and physical concerns, or, as I put it in another article (see [BROKEN LINK: blog/how-to-avoid-frustration-with-software-architecture.pre-processed.org]):

Fundamentally, I think the problem that originated the current dissatisfaction with microservices is a double confusion:

between the form (modules) and the matter (interacting running processes) of software and;

between the the form (modules) of software and the form of software building organizations (teams, executing environments, deployment pipelines …)

My conclusion

The preference for Event Sourced systems seems to stem from a confusion of physical and logical concerns and a vague desire for scaleability.

Figure 1: Ruins of Saint Lambert’s Cathedral, Liège. Destruction started in 1795 and was caused by republican revolutionaries,

References

Fowler, Martin. 2011. “Cqrs (Accessed on 2024-08-23).” https://martinfowler.com/bliki/CQRS.html.

Justin Kwan, Vignesh Ravichandran. 2022. “Performance Isolation in a Multi-Tenant Database Environment (Accessed on 2024-08-23).” https://blog.cloudflare.com/performance-isolation-in-a-multi-tenant-database-environment/.

Kiehl, Chris. 2019. “Don’t Let the Internet Dupe You, Event Sourcing Is Hard (Accessed on 2024-08-23).” https://chriskiehl.com/. https://chriskiehl.com/article/event-sourcing-is-hard.

Overeem, Michiel, Marten Spoor, and Slinger Jansen. 2017. “The Dark Side of Event Sourcing: Managing Data Conversion,” 193–204. https://doi.org/10.1109/SANER.2017.7884621.

Young, Gregory. 2017. “Versioning in an Event Sourced System (Accessed on 2024-08-23).” leanpub. https://leanpub.com/esversioning.