71–80 of 101 posts
Earlier quoted context omitted.
Looks similar to EXPLAIN QUERY PLAN: https://sqlite.org/eqp.html Raw EXPLAIN dumps bytecode, which is usually much more verbose than you want. EXPLAIN QUERY PLAN dumps a summary.
In my experience, SQLite explain plans are by far the most useless of any database out there. No concept of costing, no buffer information, no explain analyze. It's almost like they don't want you looking at it.
> I’ve been backing up to AWS, which is always a pain because it’s annoying to navigate the AWS console to generate credentials. I got so annoyed with that a few years ago that I ended up building a whole tool just to solve that one problem: uvx s3-credentials create my-existing-s3-bucket This spits out read-write credentials that are scoped JUST for that bucket. You can add --read-only or --write-only to have creden…
Earlier quoted context omitted.
Once you release software to the world, the world can choose use it however it wants. Still, the author's of SQLite document their intention for it to be used locally on their "when to use" page. > SQLite strives to provide local data storage for individual applications and devices. https://www.sqlite.org/whentouse.html
To be fair they also say > Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite.
Those are writes not hits so not directly comparable.
Earlier quoted context omitted.
So about one per second (up to ten, less conservatively). I concur. But if you think your site might ever scale beyond that, do yourself a favor and use Postgres from the get-go.
They also say it seems to work well up to 500k a day, which is quite a bit.
> I didn’t care to investigate further and > my best guess and > and presumably other things?) and > maybe there’s a bunch of Python code running inside a transaction Basically, this article has no substance. The author didn't bother to learn anything, didn't look things up. And is then wildly guessing, sometimes wrong. This is BTW the reason why (as a Debian user) if I search something Linux related and a Ubuntu for…
> I didn’t care to investigate further and > my best guess and > and presumably other things?) and > maybe there’s a bunch of Python code running inside a transaction Basically, this article has no substance. The author didn't bother to learn anything, didn't look things up. And is then wildly guessing, sometimes wrong. This is BTW the reason why (as a Debian user) if I search something Linux related and a Ubuntu for…
> I didn’t care to investigate further and > my best guess and > and presumably other things?) and > maybe there’s a bunch of Python code running inside a transaction Basically, this article has no substance. The author didn't bother to learn anything, didn't look things up. And is then wildly guessing, sometimes wrong. This is BTW the reason why (as a Debian user) if I search something Linux related and a Ubuntu for…
Off the top of my head, yesterday in work I used 2 programming languages, 2 build systems, a cloud provider, a secrets manager, a very intricate framework for client server communication in both languages, plus my VCS, editor and CI tool. That’s a fairly typical set of tools to use for one feature for me, before you go into the weeds of OS versions, specific runtime versions, databases, reverse proxies, caches, and the domain logic!
If I went deep on every single thread exposed to me, I’d never get anything done, so I have to choose my battles just like OP has done here
IMHO for a small DB I’d encourage sending out an email on each successful backup to ensure it’s completed successfully as a safety check, and zipping it up and emailing it to a known account even. With inboxes being able to take gigabytes, it’s a no brainer. This can be done daily or weekly. And yes, never allow the files to be deleted from outside. The transfer is a one way valve. If uploading, it’s a write-only ope…
It’s as much work, and scales 1000x farther than the email approach.
Earlier quoted context omitted.
To be fair they also say > Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite.
I have a 100GB SQLite DB in use that gets 8+ million rows added dally. It's on an off-the-shelf nvme SSD in a "server" that I build from 5+ year old parts. Those are writes not hits so not directly comparable.