What to Use Instead of AWS QLDB: An Audit-Grade Ledger in Postgres

The database AWS talked you into, then walked away from

Amazon Quantum Ledger Database is gone. AWS never made much noise about it, which is telling in itself: no keynote, no farewell blog, just a documentation change and an email to existing customers announcing that support would end on 31 July 2025 (InfoQ has the timeline). If you built on it, you have already had this problem land on your desk. If you were about to build on it, consider this a lucky escape.

To be fair to QLDB, the idea was good. It gave you an append-only journal where every change was chained to the last one with a cryptographic hash, so you could prove the history had not been tampered with. “Immutable ledger as a service” is a genuinely useful thing to sell to anyone doing compliance, audit, or financial record-keeping. The concept was fine. The mistake was betting a compliance-critical system on a niche managed service from a single vendor with, it turned out, little commitment behind it.

So: what do you use instead? The honest answer, including from AWS itself, is Postgres.

AWS’s own escape hatch is Postgres

You do not have to take my word for it. When AWS deprecated QLDB, the migration path it published points straight at Amazon Aurora PostgreSQL. There is an AWS Database Blog post on replacing QLDB with Aurora PostgreSQL for audit use cases, and an AWS sample repository on GitHub that migrates the old DMV tutorial ledger across as a worked example. AWS is effectively saying: the thing we sold you as special, you can rebuild on the boring relational database you already know.

There is one line in that guidance worth reading twice. Aurora gives you detailed audit logging and permanent log retention, but it does not give you QLDB’s cryptographic verifiability. That is not a footnote. It is the whole difference between “we can show you the history” and “we can prove the history was not altered,” and which one you actually need decides how much work you are signing up for. I will come back to it.

None of this needs to be Aurora, by the way. Aurora Postgres is fine, but everything below is standard PostgreSQL. Plain RDS, a container, a box under a desk, it all works the same way. That portability is part of the point.

What “append-only” actually means in Postgres

Most teams who say they need a ledger do not need cryptographic proofs. They need three things: every change recorded, nothing quietly edited or deleted after the fact, and a clean answer when a regulator or auditor asks how a decision was made. Postgres does all three, and it does them at a level most people never bother to reach for.

We use a belt-and-braces pattern on regulated builds, including the compliance platform behind our beneficial-ownership case study. Enforce append-only at the application framework, then enforce it again at the database, so the application cannot lie even if it wants to.

The database half starts by taking mutation away from the application role entirely:

-- The app can write new entries and read them. Nothing else.
REVOKE UPDATE, DELETE, TRUNCATE ON ledger_entries FROM app_role;
GRANT INSERT, SELECT ON ledger_entries TO app_role;

Revoking the grant is the real control. A bug, a bad migration, or a compromised application account simply cannot issue an UPDATE against that table, because the role has no such right. Then add a trigger as defence in depth, so an accidental grant later does not quietly reopen the door:

CREATE OR REPLACE FUNCTION ledger_no_mutate() RETURNS trigger AS $$
BEGIN
  RAISE EXCEPTION 'ledger_entries is append-only';
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER ledger_immutable
  BEFORE UPDATE OR DELETE ON ledger_entries
  FOR EACH ROW EXECUTE FUNCTION ledger_no_mutate();

Now the audit log is enforced in two places: the service framework writes every state change, and the database refuses to alter it afterwards. Belt at the framework, braces at the database. When an auditor asks how a decision got made, the answer is a query, not a folder of spreadsheets and a hopeful shrug.

Two operational notes that matter once this table is carrying real volume, because an append-only table only ever grows:

• Partition it. Range-partition by time so writes stay cheap and old periods can be detached, archived, or dropped wholesale when a retention window closes. Trying to prune an append-only table row by row is its own kind of misery.
• Read from a replica. Audit and reporting queries against years of history should never contend with the live write path. Point them at a read replica and the two workloads stop fighting.

Row-level security, per-tenant isolation, full-text search over the history, JSONB for the payloads: all of it is already in the box. This is the unglamorous, load-bearing data work that most “AI projects” and most compliance platforms actually stand on, the stuff nobody puts on the slide. It is close to where our AI data preparation work lives, and it is almost always more valuable than the model on top.

The verifiability question, answered honestly

Here is the part the “just use Postgres” takes tend to skip, and the part AWS was careful about.

Everything above is tamper-resistant, not tamper-evident. Those are different guarantees. Revoked grants and triggers stop the application from editing history. They do not stop a determined database superuser, who can disable the trigger, re-grant the permission, edit the row, and put everything back. If your threat model is “prevent accidents and application-level mistakes,” which is most teams, append-only Postgres is genuinely enough and you can stop reading here.

If your threat model includes a malicious insider with database access, or you have a regulator who literally wants cryptographic proof, you need the thing QLDB did and Aurora dropped: a hash chain. It is not exotic. Each entry stores a hash of the previous entry’s hash plus its own payload. Change any historical row and every hash after it breaks.

CREATE EXTENSION IF NOT EXISTS pgcrypto;

ALTER TABLE ledger_entries
  ADD COLUMN prev_hash bytea,
  ADD COLUMN entry_hash bytea;

-- On insert, chain this entry to the one before it:
--   entry_hash = sha256(prev_hash || canonical_bytes_of_this_row)
-- Verification is a single pass that recomputes the chain and
-- compares it to what is stored.

The one detail that actually makes this verifiable rather than theatre: the head of the chain has to be anchored somewhere the database operator cannot reach. Write the latest entry_hash periodically to append-only object storage with a retention lock, a separate account, a managed transparency log, even a notarised email if you are old-school. Without an external anchor, an insider who can rewrite the table can also recompute the whole chain, and you are back where you started. QLDB’s value came from putting verification outside your control, not from the hash function itself. Rebuild that part deliberately, or do not claim verifiability.

Most teams, when they cost this out, land in the same place: append-only tables with revoked grants for the day-to-day guarantee, and a hash chain with an external anchor added only for the specific records where someone will genuinely demand proof. Paying for a whole managed ledger service to get verifiability on data that never actually needed it was the original mistake.

This was a build-versus-buy mistake

There is a build-versus-buy decision underneath this, and it is the same one that stranded every QLDB customer. Buying a narrow, proprietary managed service is a bet on the vendor’s continued interest, and that interest is not something you control or can see the end of. QLDB was a small product inside a very large company. When the maths stopped working for AWS, “immutable and permanent” turned out to have a support-end date like everything else. (We wrote up how to reason about these calls in our build vs buy framework; this is a clean example of the exciting option quietly carrying the bigger long-term risk.)

Postgres is the opposite bet. It is boring, it is twenty-five years deep, it is not owned by anyone who can deprecate it out from under you, and the append-only patterns here have worked the same way for most of that time. When we build compliance systems that have to outlive their own vendors, longevity is exactly the property we are buying. The append-only tables we wrote for that beneficial-ownership platform will still be enforceable in a decade. QLDB did not last two years past the point AWS lost interest.

If you are migrating off QLDB right now, start with the AWS migration guide to get the data across, then decide honestly which of your records need tamper-resistance and which need genuine tamper-evidence. The first is a REVOKE statement and a trigger. The second is a hash chain and an anchor. Most of you need far more of the first than the second, and almost none of you needed a bespoke ledger database to get either.

If you would rather have someone who has built exactly this in production do the deciding with you, that is the kind of work we do. Bring the ledger you are stuck with. We will tell you which half of it you actually need.