pgr0ss

My idea for for this to add metadata to the transfers, likely with a jsonb column. But I agree that the ledger won't encompass everything. You would still have other database tables and then you'd store domain identifiers in the ledger and/or ledger identifiers in your other tables.

I updated the README and added an example test: https://github.com/pgr0ss/pgledger?tab=readme-ov-file#histor...

The idea is that the ledger implementation itself is generic and shared, and then how you use the ledger is the novel part.

> how do we efficiently get the balance of a certain account at a certain date time?

This depends on how you implement the ledger. For pgledger, I store the balance in every entry, so to find a historical balance, you just need to find the most recent entry before that time:

https://github.com/pgr0ss/pgledger/blob/df5541dcf25f416a6a24...

I have a mental TODO to add a query function to make this simpler.

I think that's a fair point. Unnesting arrays in SQL can be annoying. Here is your first example with duckdb:

  duckdb -c \
    "select * from ( \
      select unnest(assets)->>'browser_download_url' as url \
      from read_json('https://api.github.com/repos/go-gitea/gitea/releases/latest') \
    ) \
    where url like '%linux-amd64'"

Hi, I’m the author of the blog post.

> And it is bizarre to me that you could run a payments system without high-availability or immutability at its core.

I’m not sure what you’re referring to here as my post didn’t really go into these topics.

> Also putting logs in a database alongside your core data is such a bad idea.

I’m not suggesting putting all logs into the database. I’m suggesting that for a certain type of info (that is often logged), I find it more useful to put it in the database instead.

It was also covered in: https://www.braintreepayments.com/blog/switching-datacenters...