Can you qualify your statement that this is nothing?

How many CPUs and cores are available? Are we talking SSDs?

How much data is being inserted?

What are the keys and index?

15,000 per second seems like plenty much in some contexts.

The schema:

    CREATE TABLE IF NOT EXISTS users (
        id BLOB PRIMARY KEY NOT NULL,
        created_at TEXT NOT NULL,
        username TEXT NOT NULL
    );

The data:

    let user = User {
        id: uuid::Uuid::new_v4(),
        created_at: chrono::Utc::now(),
        username: String::from("Hello"),
    };

If you can't insert 15,000 of these records per second then there's something wrong with your database. I'm aware that people are all on the SQLite hype train, but this kind of stuff is table-stakes.

I really like SQLite. But this blog isn't any kind of great performance indicator for it.

This entire post reduces to:

    insert into users (id, created_at, username) values ("<id>", "<created_at>", "Hello"), ...15,000 times.

And we're going to be impressed with sqlite's performance?

Well, some people think 3 inserts per second is fast, so maybe it gives some perspective? To be fair, I wouldn’t expect those to hang around hackernews though.

I think a lot of people have forgotten or don't know how powerful CPUs are. Simple operations should be insanely fast, like easily sub-millisecond if not sub-nanosecond fast.

You can double the performance of this whole thing by inserting 2 values at a time.

I don't see why you wouldn't just bundle them all into a transaction at that point. The idea of 1 insert at a time is to roughly estimate the overhead/perf in a real environment, where you're only adding 1 entry at a time.

But, for insert, the CPU is not the bottleneck. It's I/O constrained.

Disk I/O has always been the bottleneck for writes.

Counterintuitively, write performance in modern databases is primarily constrained by disk read performance.

That said, it is increasingly rare for disk I/O to be a bottleneck for inserts. When your storage will happily sustain 10+ GB/s of write throughput, you tend to run out of things like network and memory bandwidth first.

I think it's useful stress testing for when your product goes viral.

For example, if the whole world wanted to create an account, and an account consisted of a UUID and a date, it'd take 5.4 days using this metric as a minimum viable benchmark.

While this is a tongue in cheek comment, it has a valid foundation: 15,000 seems like a large number, and 1 second seems like a small amount of time. On the other hand, 5.4 days seems like quite a large number. Likewise at small scales, 15,000/second operated at a fidelity only able to capture 0.0005% of a typical processor's clock.

It's all about context.

This is not to say that the ability to casually write 15,000 things a second to a database is not impressive in itself.

15K doesn't seem particularly noteworthy.

I made a prototype message queue in Rust that processed about 7 million messages/second. That was running from RAM.

I also had a prototype that ran from disk and it very rapidly maxed out the random write performance of the SSD. Can't remember the number but it was in the order of 15K to 30K messages a second, bottlenecked by the SSD.

If the sqlite test is writing to disk it is likely also bottlenecked at the disk.

> I made a prototype message queue in Rust that processed about 7 million messages/second. That was running from RAM.

Can you share the source code?

It was pure garbage - a failed attempt to learn Rust.

Need some garbage collection added?

To be fair it's very easy to outperform a DBMS by not offering ACID guarantees.

Agree. I know for Postgres, we are getting at least 50K / second sustained and not doing anything special - other than using bulk insert.

If WAL mode is enabled and the inserts are running in a separate thread or process then the performance will be exactly while any amount of selects are running.

For reference, a single Apache Cassandra node does about 150k inserts/second or also 150k selects/second on my laptop. All that from a single client thread using a very similar approach (also in Rust with async).