Live data from Hacker News

SQLite in Production: Lessons from Running a Store on a Single File

ultrathink.art

121–130 of 135 posts

Re: SQLite in Production: Lessons from Running a Store on a Single File

#121

How the hell did this get so much engagement, let alone as a repost? Is "SQLite" in the title really all it takes? This site was registered 8 months ago, the whole blog started in February, the first post declares its writer to be an AI CEO, most posts are about hiring and managing other AI agents, it claims to sell everything from coffee mugs to services from itself to also be the CEO of your business. This feels mo…

You are absolutely right! Everything feels off and done for engagement

Is this what we can expect in the near future?

Re: SQLite in Production: Lessons from Running a Store on a Single File

#122
I think SQLite is fantastic but it does start to fall apart at the edges sometimes.

What is more interesting to me is the fact that everyone seems to think of Postgres as the obvious alternative to SQLite. It is certainly an alternative. For me, the most opposite thing of SQLite is something like Oracle or MSSQL.

The complexity being relatively constant is the part I care about most here. Running a paid, COTS database engine on a blessed OS tends to be a little bit easier than an OSS solution that can run on toasters and drones. Especially, if you are using replication, high availability, etc.

The business liability coverage seems to track proportionally with how much money you spend on the solution. SQLite offers zero guarantees accordingly. You don't have a support contract or an account manager you can get upset with. Depending on the nature of the business this could be preferable or adverse. It really depends.

For serious regulated business with oppressive audit cycles, SQLite trends toward liability more than asset if it's being used as a system of record. That it merely works and performs well is often not sufficient for acceptance. I'm not saying that Postgres isn't capable of passing an intense audit, but I am saying that it might be easier to pass it if you used MSSQL. The cost of having your staff tied up with compliance should be considered when making technology choices in relevant businesses.

Re: SQLite in Production: Lessons from Running a Store on a Single File

#125
post #101

I see tons of articles like this, and I have no doubt sqlite proved to be a great piece of software in production environments, but what I rarely find discussed is that we lack tools that enable you to access and _maintain_ SQLite databases. It's so convenient to just open Datagrip and have a look at all my PostgreSQL instances; that's not possible with sqlite AFAIK (not even SSH tunnelling?). If something goes wrong…

I have a project to help with that: uvx datasette data.db That starts a web app on port 8001 that looks like this: https://latest.datasette.io/fixtures

Hi, thanks for your project! Do you accept pull requests? https://github.com/simonw/datasette/pull/2616 https://github.com/simonw/datasette/pull/2617

Re: SQLite in Production: Lessons from Running a Store on a Single File

#126

I think SQLite is fantastic but it does start to fall apart at the edges sometimes. What is more interesting to me is the fact that everyone seems to think of Postgres as the obvious alternative to SQLite. It is certainly an alternative. For me, the most opposite thing of SQLite is something like Oracle or MSSQL. The complexity being relatively constant is the part I care about most here. Running a paid, COTS databas…

Most of us don’t work in businesses where indemnity coverage is more important than licensing costs.

Re: SQLite in Production: Lessons from Running a Store on a Single File

#127

I think SQLite is fantastic but it does start to fall apart at the edges sometimes. What is more interesting to me is the fact that everyone seems to think of Postgres as the obvious alternative to SQLite. It is certainly an alternative. For me, the most opposite thing of SQLite is something like Oracle or MSSQL. The complexity being relatively constant is the part I care about most here. Running a paid, COTS databas…

Most of us don’t work in businesses where indemnity coverage is more important than licensing costs.

I agree these exist but I don't know about "most". Licensing costs are almost always a drop in the bucket compared to things like your salary.

Re: SQLite in Production: Lessons from Running a Store on a Single File

#128

Earlier quoted context omitted.

Well, humans also default to 'cp' until they learn the better pattern or find out their backup is missing data. Also, my n=1 is that I told Claude to create a `make backup` task and it used .backup. I don't understand the double standard though. Why do we pretend us humans are immaculate in these AI convos? If you had the prescience to be the guy who looked up how to properly back up an sqlite db, you'd have the pres…

You're confusing a workman's winking complaint about their tool, with, being unfair by not treating AI like a human.

I'm making a general observation about this frequent genre of complaint.

Re: SQLite in Production: Lessons from Running a Store on a Single File

#129

Earlier quoted context omitted.

> Backups are much more straightforward for SQLite. Not sure how? All of them can be backed up with a single command. But if you want live backups (replication) as opposed to daily or hourly, SQLite is the only one that doesn't support that.

Litestream exists?

That's a third-party tool. It's not part of SQLite.

And it's a pretty hacky usage of the WAL. If it works for you, great, but if I need replication, I'm going to want a database that supports it natively.

Re: SQLite in Production: Lessons from Running a Store on a Single File

#130

> Would We Choose SQLite Again? Yes. For a single-server deployment with moderate write volume, SQLite eliminates an entire category of infrastructure complexity. No connection pool tuning. No database server upgrades. No replication lag. These are weird reasons. You can just install Postgres or MySQL locally too. Connection pool tuning certainly isn't anything you have to worry about for a moderate write volume. You…

Yeah, the cost - both operationally and coding-wise - of running pgsql in some cloud dwarfs the cost of lost orders. "We'll just deploy less often" is tribal knowledge that will absolutely be forgotten at some point and maybe there'll be more than two lost orders. Just setup postgresql.
Post reply on HN