beanpost

Hi, the author here. I get where you're coming from. My books are also growing big right now, and indeed, they have become slower to process. Some projects in the community, such as Beanpost [1], are actually trying to solve the problem, as you said, by using an RMDB instead of plaintext. But I still like text file format more for many reasons. The first would be the hot topic, which is about LLM friendliness. While I am still thinking about using AI to make the process even easier, with text-based accounting books, it's much easier to let AI process them and generate data for you. Another reason is accessibility. Text-based accounting only requires an editor plus the CLI command line. Surely, you can build a friendly UI for SQLite-based books, but then so can text-based accounting books. Yet another reason is, as you said, Git or VCS (Ve

I wanted to share an interesting experiment I've been working on: creating a double-entry accounting system entirely in a PostgreSQL database. It's inspired by plain-text accounting, especially Beancount, a fantastic project for plain-text double-entry accounting. I've implemented most core accounting features as PostgreSQL functions, including multi-currency support, account balance calculations, and cost-basis calculations for lot matching, average cost, FIFO, or LIFO. It turns out it's easier to create a "database-based" accounting system than you'd think! The core idea is to use a custom PostgreSQL type called amount, which combines a numeric value with a currency and then write custom aggregation functions to sum amounts into balances (baskets of currencies) which can be used in other custom functions. I also created two Python scrip