How do you manage permissions with SQLLite?
That would probably boil down to "code execution on the machine means access to the DB". And that sounds pretty reasonable to me.
111–120 of 330 posts
How do you manage permissions with SQLLite?
That would probably boil down to "code execution on the machine means access to the DB". And that sounds pretty reasonable to me.
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…
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
> ...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.
Do you mean shared across networks?
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…
Would an SSD in production have solved the timeouts by increasing your write throughput?
Everything is good so far, though most of my traffic is bots probing for wordpress flaws.
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?
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.
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…
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.
No issues at all.