Live data from Hacker News

SQLite is not a toy database

antonz.org

201–210 of 364 posts

Re: SQLite is not a toy database

#201
Sqlite is not a toy, but it's so sloppy that it's not really a tool either. Like a saw with a loose blade, it can help you cut but it can also hurt you. My pet peave is the way sqlite accepts non-aggregated columns in a GROUP BY query. You'll get a result in the column, but it's not clear what it means.

More of sqlite's sloppyness is detailed here https://sqlite.org/src/wiki?name=StrictMode

Re: SQLite is not a toy database

#202

Earlier quoted context omitted.

There's also a pretty nice built-in sqlite extension for transitive closures that helps in searching hierarchical/tree structures in sqlite: https://web.archive.org/web/20141127001741/https://charlesle...

Clicking the above link takes me to https://imgur.com/32R3qLv . I fail to understand why have a blog at all if its author don't like people linking to it.

well, he doesn't like one particular group of people linking to it :-)

Re: SQLite is not a toy database

#203

Earlier quoted context omitted.

> SQLite doesn't really enforce column types[0], the choice is really puzzling to me. This is acknowledged as a likely mistake, but one that will never be fixed due to backward compatibility: > Flexible typing is considered a feature of SQLite, not a bug. Nevertheless, we recognize that this feature does sometimes cause confusion and pain for developers who are acustomed to working with other databases that are more…

> but one that will never be fixed due to backward compatibility I wonder if a fork/"new version" could address this. Like, sqlite2 (v1.0, etc.).

This would be something on the order of the python2 -> python3 transition. Meaning, it would likely take a decade. After going though that, I'm not sure it would be worth it to just change from (default) flexible data types.

Re: SQLite is not a toy database

#204

Earlier quoted context omitted.

So if you're saying everything does support a web database... then what's the reason people aren't using it for websites? Why do you say it works for "small" websites but presumably not large ones? If it's not transactions, concurrent reading, backups, or administrative tasks... then what's the issue you run into? Genuinely curious... I'm wondering if everything I've heard about "don't use SQLite for websites" is wro…

I think one valid fear is that a web application might, for multiple reasons, scale beyond a single process on a single server. This is common enough that using an embedded database can be problematic, compared to a separate RDBMS process that can be shared between processes. Some web applications are just never going to scale out for any reason, and for those SQLite might be appropriate.

Agreed, but it’s not only a question of scaling. Any app with high uptime requirements will need more than a single process from day 1.

Re: SQLite is not a toy database

#205

Two major gripe I had with SQlite 1. SQLite doesn't really enforce column types[0], the choice is really puzzling to me. Since schema enforced type check is one of the strong suit of SQL/RDMBS based data solution. 2. Whole database lock on write, this make it unsuitable to high write usages like logging and metric recording. WAL mode will help but it will only alleviate the issue, you will need row based lock solutio…

The expensify blog linked from a comment here claims:

> But lesser known is that there is a branch of SQLite that has page locking, which enables for fantastic concurrent write performance. Reach out to the SQLite folks and I’m sure they’ll tell you more

Re: SQLite is not a toy database

#206

Earlier quoted context omitted.

There's also a pretty nice built-in sqlite extension for transitive closures that helps in searching hierarchical/tree structures in sqlite: https://web.archive.org/web/20141127001741/https://charlesle...

Clicking the above link takes me to https://imgur.com/32R3qLv . I fail to understand why have a blog at all if its author don't like people linking to it.

I believe jwz did this first

Re: SQLite is not a toy database

#207
post #127
post #104

Earlier quoted context omitted.

And LibreOffice has Base, a sadly often neglected component.

Another issue with Base is the required JRE. Installing the JRE may be trivial, but it means that an error message is the first experience most people will have with Base. As for Access, it's access is limited due to the much higher price point of Business/Professional versions of Office. In terms of office suites, that version is about two to three times more expensive than an equivalent office suite from the mid-19…

> Another issue with Base is the required JRE

I thought that they dropped JRE requirement when the engine was switched to Firebird? Googling around apparently the transition wasn't quite successful :(

https://ask.libreoffice.org/en/question/279711/firebird-dead...

Re: SQLite is not a toy database

#208
post #144
post #16

> There is a popular opinion among developers that SQLite is not suitable for the web, because it doesn’t support concurrent access. No, the issue is it doesn't have high availability features: failover, snapshots, concurrent backups, etc. (Edit: oops, comment pointed out it does have concurrent backups.) SQLite isn't a toy DBMS, it's an extremely capable embedded DBMS. An embedded DBMS is geared towards serving a si…

Check out rqlite ( https://github.com/rqlite/rqlite ) for that functionality - "rqlite is a lightweight, distributed relational database, which uses SQLite as its storage engine. Forming a cluster is very straightforward, it gracefully handles leader elections, and tolerates failures of machines, including the leader. rqlite is available for Linux, macOS, and Microsoft Windows."

rqlite is a separate daemon written in Go, negating most of the reasons to choose Sqlite in the first place.

It absolutely has good use cases, but those are rather niche. You'll mostly be better off with the traditional postgres etc.

Re: SQLite is not a toy database

#209

Earlier quoted context omitted.

Backups.

Does that mean it's okay for your application to loose transactions (which occured between the backup point and the failure point) or do you have other mitigations ?

Isn't that how all backups work? If you need to prevent data loss then backups probably aren't your tool of choice. And if you're paranoid about data loss then any replication lag is also unacceptable.

* I'm worried about my server blowing up: Transactions have to be committed to more than one DB on separate physical hosts before returning.

* I'm worried about my datacenter blowing up: Transactions have to be committed to more than one DB in more than one DC before returning.

Re: SQLite is not a toy database

#210

SQLite is a really neat thing. I was looking at extensions and how to augment it; you could even add a pg_notify -like feature: https://sqlite.org/c3ref/update_hook.html and have worker processes doing what would amount to out of process stored procedures in postgres (or UDF in SQLite) -- in any language you'd like. You can only register one callback per table tho, although you could from this callback fire other fun…

The Firebird database can run both as a separate server and in embedded mode. I wish more databases works design for this sort of flexibility.
Post reply on HN