I think they're trying to not shame other services, but yes the comparison is vs networked whether that's local on loopback or not. For a small query, which is what they're talking about, it's not inconceivable that formatting into a network packet, passing through the userspace networking functions, into and through kernel, all back out the other side, then again for the response, is indeed meaningfully slower than a simple function call within the program.

Yes, I explicitly said localhost is slower. But the article doesn't say what it's comparing to nor provide any measurements.

Connecting to localhost still involves the network stack and a fair bit of overhead.

SQLite is embedded in your program's address space. You call its functions directly like any other function. Depending on your language, there is probably some FFI overhead but it's a lot less than than an external localhost connection

Even if you're on the same local server, you're still going over a socket to a different service, whereas with sqlite you remain in the same application / address space / insert words I don't fully understand here. So while client/server SQL servers are faster locally than on a remote server, they can (theoretically) never be as fast as SQLite in the same process.

Of course, SQLite and client/server database servers have different use cases, so it is kind of an apples and oranges comparison.

Yes, I already said all of this. But you haven't clarified what the article is saying

I think the most common set up is to have your application server and DB on different hosts. That way you can scale each independently.

Quite likely! But the article doesn't say this