Hacker News: giovannibonetti

New comment by giovannibonetti in "SQLite Is a Library of Congress Recommended Storage Format"

giovannibonetti — Thu, 07 May 2026 16:31:58 +0000

If it's going to be read-only, why not make it a Parquet file instead? It should result in a smaller file size due to columnar compression.

DuckDB has built-in capability to read Parquet files with HTTP range requests.

New comment by giovannibonetti in "VS Code inserting 'Co-Authored-by Copilot' into commits regardless of usage"

giovannibonetti — Sun, 03 May 2026 13:59:44 +0000

>There was a time that Google cared deeply about UX. Now, on macOS Google remaps CMD-G in Google Docs to launch some LLM bullshit

That reminds me of a few years ago when Android phones replaced the behavior of "long press sleep/power button" from "shut down" to "ask AI about what's in your screen". Perhaps a manager got promoted somewhere for "raising AI usage" in Android phones.

New comment by giovannibonetti in "Does Postgres Scale?"

giovannibonetti — Fri, 01 May 2026 11:35:07 +0000

As far as I can tell, Postgres is not designed with this inclination towards doing lighter work when clients are waiting and piling up maintenance work to do in background. I think the background work it does is mostly running vacuum on tables now and then.

Contrast that with ClickHouse, for example. It operates in a different niche than Postgres (OLAP instead of OLTP) – with their merge tree engine family [1] that does data deduplication in background.

There is one project of modernizing Postgres' storage engine called OrioleDB [2], but I think the company got acquihired by Supabase [3] and maybe the project has not been progressing very quickly since then.

[1] https://clickhouse.com/docs/engines/table-engines/mergetree-... [2] https://www.orioledb.com/ [3] https://supabase.com/blog/supabase-acquires-oriole

New comment by giovannibonetti in "Does Postgres Scale?"

giovannibonetti — Fri, 01 May 2026 11:17:20 +0000

Yes, partitioning will decrease a bit the read performance of queries not correlated with the partition key. That's why you need to periodically merge smaller partitions, so that you can keep the overall partition count bounded.

It is a lot of admin work, but if you really need to scale up Postgres write throughput, I don't see many other options without increasing hardware costs.

I assume you have already picked the low-hanging fruit discussed in the neighboring comments - batch writes, make sure you are using COPY instead of INSERT, tune Postgres parameters adequately and use the fastest disk you can grab for the WAL.

New comment by giovannibonetti in "You can beat the binary search"

giovannibonetti — Fri, 01 May 2026 00:49:39 +0000

Say, if you know the function is a polynomial of degree N, with N+1 datapoints you can find it – e.g. with Lagrange's polynomial, although the finite precision of computer numbers might make that more complex.

New comment by giovannibonetti in "Does Postgres Scale?"

giovannibonetti — Thu, 30 Apr 2026 20:48:03 +0000

With some extra admin work, you can greatly increase your insert throughput, as long as the table load is comprised mostly of inserts: 1. Partition your table by range of a monotonic ID or timestamp. Notice the primary key will have to contain this column. A BIGINT id column should work fine; 2. Remove all the other indexes from the partitioned table. Add them to all the partitions, except the latest one. This way, the latest one can endure a tough write load, while the other ones work fine for reads; 3. Create an admin routine (perhaps with pg_cron) to create a new partition whenever the newest one is getting close to the limit. When the load moves to the newer partition, add indexes concurrently to the old one; 4. You'll notice the newest partition will the optimized for writes but not reads. You can offset some of that by replacing BTREE secondary indexes with BRIN [1], particularly the one with bloom operator (not to be confused with Postgres Bloom regular indexes [2]). BRIN is a family of indexes more optimized for writes than reads. If the partition is not too large, it shouldn't be too bad to read from it. 5. Later you can merge partitions to avoid having too many of them. Postgres has commands for that, but I think they lock the whole table, so a safer bet is to copy small partitions into a new larger one and swap them manually.

[1] https://www.postgresql.org/docs/current/brin.html [2] https://www.postgresql.org/docs/current/bloom.html

New comment by giovannibonetti in "NimConf 2026: Dates Announced, Registrations Open"

giovannibonetti — Tue, 14 Apr 2026 15:58:12 +0000

That's why these niche languages need state-of-the-art compilers that enforce invariants more strongly. This way, they can catch most of the subtle bugs the LLM produces, sort of like antibodies.

New comment by giovannibonetti in "Servo is now available on crates.io"

giovannibonetti — Mon, 13 Apr 2026 16:22:03 +0000

For those of you using a browser to generate PDFs, the Rust crate you should look into is Typst [1]. Regardless of your application language, you can use their CLI.

It takes some time to get used to their DSL to write PDFs, but nowadays with AI that shouldn't take too long.

[1] https://crates.io/crates/typst

New comment by giovannibonetti in "How We Synchronized Editing for Rec Room's Multiplayer Scripting System"

giovannibonetti — Sun, 22 Mar 2026 13:06:54 +0000

I find it fascinating when different people independently arrive at the same architecture when working on a hard problem like this. In my company we built our offline-first apps with PowerSync, which has the same idea of optimistic local changes while waiting for the central server to acknowledge the definitive changes. In PowerSync's case, the sync engine reads Postgres replication logs directly.

New comment by giovannibonetti in "“Your frustration is the product”"

giovannibonetti — Thu, 19 Mar 2026 16:35:02 +0000

Micro-payments, probably

New comment by giovannibonetti in "Machine Payments Protocol (MPP)"

giovannibonetti — Wed, 18 Mar 2026 19:45:45 +0000

For those of you in Brazil, my company jota.ai has built a financial AI-assistant that you can chat with to open a bank account, connect with accounts from other banks, make instant Pix payments with any of them, all of that through WhatsApp right now. We're working hard to release long-running agents soon that can do increasingly complex workflows involving payments and whatnot.

Please let us know if you have suggestions of what complex workflows you would like to build.

New comment by giovannibonetti in "Show HN: Oxyde – Pydantic-native async ORM with a Rust core"

giovannibonetti — Tue, 17 Mar 2026 00:08:10 +0000

You might be interested in a library that flips around the concept of an ORM, like sqlc [1] or aiosql [2]. You specify just what you want from the database, without needing to couple so much API with database tables.

[1] https://sqlc.dev/ [2] https://nackjicholson.github.io/aiosql/

New comment by giovannibonetti in "Zig – io_uring and Grand Central Dispatch std.Io implementations landed"

giovannibonetti — Sat, 14 Feb 2026 18:54:46 +0000

That's the space where Go shines

New comment by giovannibonetti in "It's 2026, Just Use Postgres"

giovannibonetti — Fri, 06 Feb 2026 23:38:23 +0000

> OTOH, if and only if you design your schema to exploit MySQL’s clustering index (like for 1:M, make the PK of the child table something like (FK, some_id)), your range scans will become incredibly fast. But practically no one does that.

You can achieve that with Postgres as well if you accept duplicating the data by adding an index with an include clause containing all the non-key columns you want to return in the SELECT clause. This way, you'll get fast index-only scans.

New comment by giovannibonetti in "European Commission Trials Matrix to Replace Teams"

giovannibonetti — Thu, 05 Feb 2026 18:17:51 +0000

I think the PowerSync [1] team is missing out on an opportunity to showcase their impressive data sync technology by building a minimalist Slack clone.

[1] https://www.powersync.com/

New comment by giovannibonetti in "Unconventional PostgreSQL Optimizations"

giovannibonetti — Tue, 20 Jan 2026 23:27:27 +0000

Clustered indexes only save up to 2x write amplification in the very rare case where you're indexing the entire table (e.g. if it has very few columns).

However, that is usually the least of your concerns with write amplification. If you don't batch your writes, you can easily get 100x write amplification. For any primary key or any other index not strongly correlated with your INSERTs, you can get perhaps another 100x write amplification even if you batch you writes.

New comment by giovannibonetti in "Command-line Tools can be 235x Faster than your Hadoop Cluster (2014)"

giovannibonetti — Sun, 18 Jan 2026 12:17:45 +0000

You assume it is valid, until it isn't and you can have different strategies to handle that, like just skipping the broken part and carrying on.

Anyway, you write a state machine that processes the string in chunks – as you would do with a regular parser – but the difference is that the parser is eager to spit out a stream of data that matches the query as soon as you find it.

The objective is to reduce the memory consumption as much as possible, so that your program can handle an unbounded JSON string and only keep track of where in the structure it currently is – like a jQuery selector.

New comment by giovannibonetti in "Ask HN: Which is the best sync engine?"

giovannibonetti — Tue, 06 Jan 2026 19:50:08 +0000

I have been using Powersync, and it works great for mobile apps with offline-first functionality.

New comment by giovannibonetti in "Databases in 2025: A Year in Review"

giovannibonetti — Mon, 05 Jan 2026 12:35:28 +0000

I think only Turso — SQLite rewritten in Rust — supports that.

New comment by giovannibonetti in "Helion: A high-level DSL for performant and portable ML kernels"

giovannibonetti — Fri, 07 Nov 2025 22:42:51 +0000

That's Mojo's selling point.

https://www.modular.com/mojo