kiitos (u/kiitos) - Readit News

kiitos commented on 100k TPS over a billion rows: the unreasonable effectiveness of SQLite andersmurphy.com/2025/12/... · Posted by u/speckx

andersmurphy · 14 days ago

I'd argue the opposite most applications are fine with an hour of downtime a month and arguably much more downtime then that. The recent AWS and Cloudflare outages have proven that.

You can achieve zero downtime with Sqlite if you really need to.

TPS is not a synthetic metric when you cap out at 100 TPS because of Amdahl's law and your users having a power distribution.

kiitos · 14 days ago

1h of downtime per month means you're delivering at best two 9s of availability. again that may be fine for lots of applications but it's trivial scale, and certainly a couple orders of magnitude below what aws and cloudflare provide

taking a step back, if your application's db requirements can be satisfied by sqlite [+replication] then that's great, but that set of requirements is much narrower, and much easier to solve, than what postgres is for

kiitos commented on 100k TPS over a billion rows: the unreasonable effectiveness of SQLite andersmurphy.com/2025/12/... · Posted by u/speckx

andersmurphy · 14 days ago

Oh there are a bunch of considerations.

You're going to want persistent storage on your server, not ephemeral. You'll also want NVME. A lot of the time you're going to end up on bare metal running a single server anyway.

You're going to have down time for migrations unless you're very clever with your schema and/or replicas.

Litestream for me at least is what makes SQLite viable for a web app as prior to that there wasn't a good replication story.

With litestream it's much easier to have a backup on standby. That being said where I have used it in production some amount of downtime has been acceptable so mileage may vary.

kiitos · 14 days ago

> You're going to have down time for migrations unless you're very clever with your schema and/or replicas.

probably worth stating these kinds of design considerations/assumptions up-front

i'm sure lots of applications are fine with "downtime for [database] migrations" but lots more are definitely not, especially those interested in synthetic metrics like TPS

kiitos commented on 100k TPS over a billion rows: the unreasonable effectiveness of SQLite andersmurphy.com/2025/12/... · Posted by u/speckx

matthewaveryusa · 14 days ago

The only caveat being this assumes all your data can fit on a single machine, and all your processing can fit on one machine. You can get a a u-24tb1.112xlarge with 448 vcores, 24TB RAM for 255/hour and attach 64TB of EBS -- that's a lot of runway.

kiitos · 14 days ago

and that your application doesn't need to be resilient to host or network faults

kiitos commented on A million ways to die from a data race in Go gaultier.github.io/blog/a... · Posted by u/ingve

zbentley · 20 days ago

GP didn’t say “setting a ‘bool’ value to true”, it referred to setting a “field”. Interpreted charitably, this would be done in Go via a type that does support atomic updates, which is totally possible.

kiitos · 20 days ago

"setting a field to true" clearly means `x.field = value` and not `x.field.Set(value)`

kiitos commented on A million ways to die from a data race in Go gaultier.github.io/blog/a... · Posted by u/ingve

kiitos · 21 days ago

> I have been writing production applications in Go for a few years now.

sorry, what?

https://gaultier.github.io/blog/a_million_ways_to_data_race_...

this code is obviously wrong, fractally wrong

why would you create a new PricingService for every request? what makes you think a mutex in each of those (obviously unique) PricingService values would somehow protect the (inexplicably shared) PricingInfo value??

> the fix

https://gaultier.github.io/blog/a_million_ways_to_data_race_...

what? this is in no way a fix to the problem.

it's impossible to believe the author's claims about their experience in the language, this is just absolute beginner stuff..

kiitos commented on A million ways to die from a data race in Go gaultier.github.io/blog/a... · Posted by u/ingve

gf000 · 21 days ago

This is not true in the general case. E.g. setting a field to true from potentially multiple threads can be a completely meaningful operation e.g. if you only care about if ANY of the threads have finished execution.

It depends on the platform though (e.g. in Java it is guaranteed that there is no tearing [1]).

[1] In OpenJDK. The JVM spec itself only guarantees it for 32-bit primitives and references, but given that 64-bit CPUs can cheaply/freely write a 64-bit value atomically, that's how it's implemented.

kiitos · 21 days ago

> setting a field to true from potentially multiple threads can be a completely meaningful operation e.g. if you only care about if ANY of the threads have finished execution.

this only works when the language defines a memory model where bools are guaranteed to have atomic reads and writes

so you can't make a claim like "setting a field to true from ... multiple threads ... can be a meaningful operation e.g. if you only care about if ANY of the threads have finished execution"

as that claim only holds when the memory model allows it

which is not true in general, and definitely not true in go

assumptions everywhere!!

kiitos commented on A million ways to die from a data race in Go gaultier.github.io/blog/a... · Posted by u/ingve

Mawr · 21 days ago

> The http.Client docs mention concurrent usage is safe, but not modification.

Subtle linguistic distinctions are not what I want to see in my docs, especially if the context is concurrency.

kiitos · 21 days ago

the distinction between "concurrent use" and "concurrent modification" in go is in no way subtle

there is this whole demographic of folks, including the OP author, who seem to believe that they can start writing go programs without reading and understanding the language spec, the memory model, or any core docs, and that if the program compiles and runs that any error is the fault of the language rather than the programmer. this just ain't how it works. you have to understand the thing before you can use the thing. all of the bugs in the code in this blog post are immediately obvious to anyone who has even a basic understanding of the rules of the language. this stuff just isn't interesting.

kiitos commented on Several core problems with Rust bykozy.me/blog/rust-is-a-... · Posted by u/byko3y

rowanG077 · 23 days ago

Having run into memory issues in go but not (yet) in rust I would tend to disagree with this. It's really not hard or esoteric to run into it in go.

kiitos · 22 days ago

"running into memory issues" doesn't relate to memory safety as a property

kiitos commented on Verifying your Matrix devices is becoming mandatory element.io/blog/verifying... · Posted by u/LorenDB

tptacek · a month ago

Matrix and Signal have very different objectives. Matrix wants to be an encrypted IRC or Slack. Signal wants to be a secure messenger you can entrust your life to. They are both worthy projects; there's not as much overlap as people think.

kiitos · a month ago

> Matrix wants to be an encrypted IRC or Slack

matrix's users want it to be a decentralized/encrypted irc/slack, but unfortunately matrix's maintainers believe their mandate is to build a next-gen tcp/ip (or something very close to that)

which dooms the project