Live data from Hacker News

Why SQLite is so great for the edge

blog.turso.tech

111–120 of 148 posts

Re: Why SQLite is so great for the edge

#111

For a tenanted SAAS app SQLite at the edge is a really compelling architecture. You have a single DB per customer/company/group with all their users woking against that. It can operate at the edge, closest to where the majority of the customers users are. SQLite could scale to even quite large customers with this. Another really compelling architecture is a DB per user, with partial/selective sync between the nodes.…

This also sounds like CouchDB: https://couchdb.apache.org/

Re: Why SQLite is so great for the edge

#112
post #52
post #3

> It’s borderline impossible to compare it against networked database management systems like MySQL or Postgres, because SQLite is a library that operates on a local file — it bypasses all the costs incurred by the network, layers of serialization and deserialization, authentication, authorization, and more. Postgres can run locally, communicating via a Unix socket. You should try benchmarking this before stating tha…

I've done the SQLite benchmark a few times. You can insert somewhere in the range of 10~20k rows per second if you are using NVMe (i.e. ~50uS per row). Requires some pragmas (i.e. WAL). This is 100% serialized throughput. No clue what Postgres would manage, but I suspect it would be about an order of magnitude higher latency in the happy case.

> No clue what Postgres would manage, but I suspect it would be about an order of magnitude higher latency in the happy case.

Unless you’re talking 1 versus 10 microseconds (or less), I don’t think Postgres will have an order of magnitude higher latency. And if we are talking this range, why would it matter for a web app where the client’s latency is almost certainly >1 millisecond?

Re: Why SQLite is so great for the edge

#113

Earlier quoted context omitted.

> detailed understanding on the forces on the car and how it behaves But at 4000 samples per second? You'd think twenty would be plenty. NyQuist: 4000 samples per second means we are looking to get information about an up to 1800 Hz signal. A6 on the piano keyboard (excluding harmonics). Sorry, I mean Nyquist. I was confused by NyQuil, the night time flu medicine.

At 250kph and 4kHz sampling rate the car moves 17mm per sample, or about 2/3 of an inch. Doesn't seem unreasonable to want to sample at that rate, especially for tweaking suspension and such.

A sound wave moves 85 mm in that time at Mach 1, around 340 m/s. That doesn't mean we need to sample a sound that has no components above 20 Hz, using 4000 samples per second.

The propagation speed can be misleading.

All that matters is whether there are oscillations in the suspension that go up to 1800 Hz, not how fast the car is going forward. If there are, those would have to be harmonics. You'd think would be beyond the frequency response of the suspension. Suspensions are heavy, bulky components and are heavily dampened (which is a kind of low-pass filter).

If the suspension moves anywhere near 17 mm per sample (250 km/h vertically), that car is in serious trouble.

Re: Why SQLite is so great for the edge

#114
post #3

> It’s borderline impossible to compare it against networked database management systems like MySQL or Postgres, because SQLite is a library that operates on a local file — it bypasses all the costs incurred by the network, layers of serialization and deserialization, authentication, authorization, and more. Postgres can run locally, communicating via a Unix socket. You should try benchmarking this before stating tha…

> communicating via a Unix socket. Which is already IPC, which already makes it slower than having the data never crossing process boundaries. No benchmark required.

I don’t disagree with this. I disagree with whether these microseconds of difference matter when you’re serving a web page with milliseconds of latency.

Re: Why SQLite is so great for the edge

#115

Earlier quoted context omitted.

Good question. As a non-racer who enjoys watching racing, I'd imagine at least some accelerometers/gyros and load cells if they got them, and possibly Pitot tubes or similar for measuring aerodynamics when testing, to get a detailed understanding on the forces on the car and how it behaves. Motor currents probably up there too, to catch current spikes. Curious to see how far off I am :)

> detailed understanding on the forces on the car and how it behaves But at 4000 samples per second? You'd think twenty would be plenty. NyQuist: 4000 samples per second means we are looking to get information about an up to 1800 Hz signal. A6 on the piano keyboard (excluding harmonics). Sorry, I mean Nyquist. I was confused by NyQuil, the night time flu medicine.

I read it as an aggregate 4000 samples per second -- so across 40 sensors that's only 100sps

Re: Why SQLite is so great for the edge

#118
post #52
post #3

> It’s borderline impossible to compare it against networked database management systems like MySQL or Postgres, because SQLite is a library that operates on a local file — it bypasses all the costs incurred by the network, layers of serialization and deserialization, authentication, authorization, and more. Postgres can run locally, communicating via a Unix socket. You should try benchmarking this before stating tha…

I've done the SQLite benchmark a few times. You can insert somewhere in the range of 10~20k rows per second if you are using NVMe (i.e. ~50uS per row). Requires some pragmas (i.e. WAL). This is 100% serialized throughput. No clue what Postgres would manage, but I suspect it would be about an order of magnitude higher latency in the happy case.

I'm pretty sure sqlite is capable of significantly higher throughput that 10-20k rows per second depending on the workload. Inserts can be much faster if they are batched in large transactions and prepared statements are used to avoid sql parsing for each row. This only works of course if your workload can be batched.

Re: Why SQLite is so great for the edge

#119

This no need to compile SQLite into your Cloudflare Worker. We provide it native on our platform as D1. And it gives you replication. https://blog.cloudflare.com/d1-turning-it-up-to-11/ Also, I think the idea of “edge” doesn’t make a ton of sense. What we really need is code and data that move around as needed for the best performance. See: https://blog.cloudflare.com/announcing-workers-smart-placeme... What people c…

Does D1 support FTS?

`wrangler d1 execute abcdtest --command 'CREATE VIRTUAL TABLE people USING fts5(firstName, lastName);'` succeeds with no errors, so I'd say it does.

Re: Why SQLite is so great for the edge

#120
post #31
post #7

I want to hear "What's not great using SQLite compare to PostgreSQL" instead .

No foreign keys by default. Using them means that every connecting session must toggle it on. Forget one and it will be free to violate referential integrity. One writer. Any session that issues BEGIN TRANSACTION and then hangs halts all dml. WAL mode confusion. WAL cannot safely be used on network filesystems, and it breaks ACID on ATTACHed databases, among other problems. Date and time types don't really exist. The…

These are all fair points though they mostly can be addressed at the application layer. One could, for example, use a wrapper that opens the sqlite library and immediately turns foreign keys on. One does this once per language in your project and never think about it again. Similarly, type constraints can be enforced at the application layer.

I agree that it would be nice if some of these things were built in but at least sqlite is reliable when configured and used in particular ways.

Post reply on HN