Hacker News Reader

Comment by TickleSteve | Hacker News Reader

This is sqlite, not a db-server like mysql, its an in-process db that forgoes those sort of issues in the name of performance and lightness.

View on HN

yes it did that because sqlite is (was) an embeded db, the whole point of projects like this is to elevate sqlite from that status? NO?

I wish sqlite was performance focused. Perf is pretty much always worse than a db server, even after tuning the pragmas (the way it locks tends to limit single threaded perf and concurrency). Main benefit of sqlite is just its portability since you can easily embed it. It's nice for slapping a db backend on a client installed app, where trying to spin up a db server would be problematic.

There's probably an extension for permissions in sqlite but out of the box the db files are plaintext (you need an extension for that).

Good starting point for extensions: https://antonz.org/sqlean/

the SQLite db files are definitely not plain text. (only in a cryptographer's jargon, but even that is not true, because they might be encrypted internally using an extension)

Any numbers to support that claim? SQLite performs pretty well when just reading. Only write-intensive workloads are usually slower than on pgsql and others.

In my experience, SQLite has excellent performance if you use it correctly. It can easily do 10k to 500k inserts/second, depending on the workload.

SQLite only supports a single writer at a time, but does support concurrent reads. There is also an experimental branch that supports concurrent writes.

SQLite is absolutely focused on performance and excels at it for its intended use cases. You can read about them here: https://www.sqlite.org/whentouse.html

With the right approach, performance can be good. My co-founder wrote this overview of SQLite performance optimizations: https://www.powersync.co/blog/sqlite-optimizations-for-ultra...

Reply on news.ycombinator.com