You can add the following statements in the first example and click "Run" button in order to understand the underlying tables' structure and contents mentioned in the example:
SELECT * FROM person;
SELECT * FROM follows;
You can explore the database used in this example with any valid PostgreSQL statements.
VictoriaLogs could be a good alternative: it stores logs in column-oriented compressed format, so they occupy small amounts of disk space, and it consists of a single small executable without external dependencies, which stores the logs into a single directory on a local filesystem.
It would be great comparing NanoTDB to VictoriaMetrics. Both are optimized for running on Raspberry Pi. Both have built-in web UI for the exploration of the stored metrics. Both consist of a single executable written in Go, which stores the collected metrics to a single directory on a local filesystem. I don't know whether NanoDB is optimized for low-cost flash storage with small number of lifetime writes. VictoriaMetrics is optimized for such a storage, so it saves the flash drive life.
I have used VM for a while and for my use case it was way better than influxdb. VM process takes 70 to 100Mb memory on my system. Not bad, but not great. NanoTDB takes just about 10 to 20Mb, and that does include the dashboard. NanoTDB is much simpler in design and does have less features, but I think that's it's power. I didn't compare disk usage. NanoTDB is also very optimized for SD usage. You can tune it to be very resilient to shutdowns but less SD friendly, or you can tolerate missing some metrics and not write everything to the WAL file, and you can have anything in between.
https://lwn.net is a goldmine of great contents about Linux kernel.
Let me explain why I post links to posts from https://internals-for-interns.com . I hate AI slop. The author of these posts uses AI for generating these posts - this is clearly visible via AI-generated images, emojis and em dashes. But the posts themselves do not contain misleading slop you could see in a typical AI-generated content. These posts are very clear and accurate. While they contain some inaccuracies and mistakes, the number of these mistakes is very low. These posts help learning and understanding complex technical topics such as internals of Go, filesystems, databases and linux kernel, by reading a clear easy to understand text.
It is important to differentiate between low-quality AI slop and high-quality contents generated with the help of AI. The posts at https://internals-for-interns.com belong to the second category.
C. "...using initramfs. The call to prepare_namespace() must be skipped. This means that a binary must do all the work. Said binary can be stored into initramfs either via modifying usr/gen_init_cpio.c or via the new initrd format, an cpio archive. It must be called “/init”. This binary is responsible to do all the things prepare_namespace() would do..."
