Live data from Hacker News

Ask HN: Have you used SQLite as a primary database?

news.ycombinator.com

111–120 of 330 posts

Re: Ask HN: Have you used SQLite as a primary database?

#111
post #79

How do you manage permissions with SQLLite?

I imagine, since SQLite does not connect over the network but is just part of the program, the permission model is "if the process is allowed to read the file, it can do things".

That would probably boil down to "code execution on the machine means access to the DB". And that sounds pretty reasonable to me.

Re: Ask HN: Have you used SQLite as a primary database?

#112
post #33

I do not quite understand the premises: > Given the complexity Which complexity? It is the simplest possible widespread, reliable and effective solution. Which makes it a primary choice. > it seems like there are use cases or needs here that I'm not seeing On the contrary, the use cases for the traditional Relational DB engines are defined: when you need a concurrency manager better than filesystem access. (Or maybe…

> ... the possibility of recursion was implemented only recently, etc).

Noting that "recently" was August 2014 (version 3.8.6), according to https://sqlite.org/oldnews.html.

The "missing" right/full join types just hit trunk this past week and are still being debugged: https://sqlite.org/src/info/f766dff012af0ea3

Re: Ask HN: Have you used SQLite as a primary database?

#113

> ...I periodically hear about projects that use/have used sqlite as their sole datastore. SQLite==exclusive access, no sharing, unless read-only. Basically, it provides a SQL convenience for local usage.

If you need to safely have multiple processes read and write to the same data, it does that great. The writes are serialized, but that's typically how an in-memory shared resource would be implemented as well.

Do you mean shared across networks?

Re: Ask HN: Have you used SQLite as a primary database?

#114

Things worked well at the outset, especially in local development against my NVMe drive for my small CRUD application. Then, with a little traffic, things continued to go well in production. But as traffic scaled up (to 1-5 QPS, roughly 25% writes), they fell apart. Hard. Because my production environment was spinning rust, IO contention was a real issue and totally absent from development. This manifested as frequen…

So you were using an HDD, not an SSD?

Would an SSD in production have solved the timeouts by increasing your write throughput?

Re: Ask HN: Have you used SQLite as a primary database?

#115
This isn't a typical use case. FWIW, a decade ago, we used sqlite as the persistence mechanism for an in-memory KV store called membase. (See https://github.com/membase/ep-engine). This was powering 50M+ DAU traffic in production for very intense write-heavy traffic. It did its job well. Around that time we also considered leveldb (and rocksdb a bit later) as alternative to sqlite.

Re: Ask HN: Have you used SQLite as a primary database?

#117
post #42

Question for people using SQLite in prod: how do you cope if your app is running on a platform like Heroku or Cloud Run, rather than a proper server or VM? Have you found a solution for the fact that those environments, and disk, is ephemeral?

Postgress

About 2 years ago I wrote my own blog engine so I could get up-to-speed with NodeJS: https://andrewrondeau.herokuapp.com/

I would have loved to do SQLite with some kind of "magic" backup, as SQLite is more than enough to handle a personal blog. (It certainly would make development easier!) However, at the time Heroku only offered Postgress.

Re: Ask HN: Have you used SQLite as a primary database?

#118
post #32

Here's an all-time great post about why you might consider SQLite in production with data about performance: https://blog.wesleyac.com/posts/consider-sqlite I use SQLite in production for my SaaS[1]. It's really great — saves me money, required basically no setup/configuration/management, and has had no scaling issues whatsoever with a few million hits a month. SQLite is really blazing fast for typical SaaS workloads…

What is the point of using SQLite under a web service?

I thought people complained how MySQL sucks and PostgreSQL rocks for being right and SQLite was nowhere near being right or performant. (Things seem to be getting better with strict column types these days.)

I've recently migrated a smallish service from MySQL to PostgreSQL and figured it's quite a work if you're not careful writing by the SQL standard which means if the service had gotten bigger, your chance of moving away from SQLite kind of walks away.

So, why not use a safer choice to begin with? Nothing is complicated running MySQL/PostgreSQL unless you've sold yourself to AWS to care for the cost and don't know how to run a DB instance yourself.

Post reply on HN