https://benchmark.clickhouse.com/#system=+liH|Hoaus|DcD|ucqs...

Measurements and context is so situational that it would be useless anyway imo.

It is not like any DB company is writing blog posts with benchmarks compared to hardware limits. DuckDB had blog posts that has sentences like "You are doing it wrong if you are not using HTTP api on your database in 2026", last time I saw their blog.

I also think object storage is bad in this case. And rust is no a no-no for a database project like this, because it is not ergonomic to do static allocation and arena allocators in rust. And parquet is trash for performance because of many reasons like supported compression formats etc.

Operators cause issues because it is not possible to cleanly express error output from an operator, it is not possible to express the bit-width of the operation, have to understand precedence.

All of these issues cause other downstream issues.

Why not add_u64()?

I know several people that had their lives severely impacted by these things and they were all regular people.

echo '#include ' | gcc -E -dM -xc - | grep -i "read"

To get the real values on your PC to make sure.

I had LLMs give wrong numbers or constant definitions several times but getting it to generate a command like this and seeing it for myself works every time.

Also chromium docs has a table:

https://www.chromium.org/chromium-os/developer-library/refer...

It would be very useful to just make this website directly link to the syscall number.

And the "blue collar" guy in the top photo seems like it is pushing that feeling.

Also this mechanic will never change without heavy wealth taxing and regulating prices of essentials like housing. Basically the entire world is in the same situation.

Young people should just not vote for old people in principle anymore.

You can limit the concurrent requests that can be handled at a time to 2000 and limit memory per request handler to 2MB.

So you allocate 2000 x 2MB at program start.

Then you crate an arena allocator with (2MB limit) when starting to handle a request.

It will just fail if a request uses more memory than 2MB. This means you will basically never have OOM issues or a request using unexpected amount of memory to crash the server.

You also have performance benefits like:

- Allocation operation is basically an integer increment.

- Memory for a request is laid out linearly in memory and likely is pre-populated so you won't have page fault into the kernel.

- It is very unlikely to have double free or other memory management mistakes.

You can also fuzz the system in several ways to make sure requests can really never exceed that amount of memory usage so you don't have surprises in runtime.

If a request by a user really exceeds that much memory usage, you can just fail that request and log it so it will be debugged and fixed later.

You also don't need data structures like SmallVec (rust version of the thing) that are hybrid stack/heap allocated.

There are many intricacies to this approach but it works much better on scale when you have a large program that handles a large amount of memory.

It is super difficult to debug and fix memory usage issues on global allocator only programs in my experience.

I tried to fix one such issue on a database-like program in rust and it was impossible.

Also this means you don't absolutely need ownership/lifetime safety.

I am using this pattern in a C-like C++ codebase I have and it works really well.

What I understand from that is, byte code is portable while machine code isn't.

So you can write a byte code interpreter in C and you have fully cross platform toolchain.

It is also supposedly easier to generate bytecode compared to generating something like x86_64 machine code or assembly.

Imo what matters more is the execution and not the idea anyway so you shouldn't care about this:

> Any comments or suggestions, including, "that's a bad idea, you will fail because of XYZ", or, "save yourself the effort, here's one I wrote earlier..."?

The quote at the top isn't related to what any of this is so it is pretty funny while being obnoxious

You can try to understand some of it by doing some measurements and doing some napkin math using the hardware limits like internet bandwidth or IO read/write etc.

Akshually, you can never rewrite your code.

If you go to squarespace domain management website you will see it is utter garbage in terms of experience. It doesn’t have to be like this but the people that make it just aren’t good enough or don’t care.

Unfortunately it is same with blockchain and LLMs soon.

Blockchain can be super useful but there are hard problems that need to be solved and people that vacuum the investment up just aren’t interested in solving problems.

I see the same problem with LLMs because big companies want to pump horror stories and vibe coding instead of code review or security review or cost stabilization/profitability etc.

The people that behave this was just don’t have a chance of long term success imo.

These technologies could have been so much better if they were developed by different people