We’re pretty happy with SQLite and not urgently interested in a fancier DBMS

Re:We’re pretty happy with SQLite and not urgently intereste... by zackelan on Sunday June 19, 2016 @06:54PM (#11935124)

Only one process can have a SQLite database file open for writes at a time. Multiple processes/threads can read, however.

That's about it. I'm hesitant to describe it as an "issue" with concurrency because that has connotations that it's a problem with SQLite that the authors should address. Rather, it's part of the simplicity that is a key design feature of SQLite.

As SQLite's own documentation[0] says, it doesn't compete with client/server databases like Oracle/Postgres/MySQL - it competes with fopen() (edit: not a system call, see below), hand-maintained serialization/pickling formats, etc.

0: https://www.sqlite.org/whentouse.html

[ Parent | on HN ]

Re:We’re pretty happy with SQLite and not urgently intereste... by asveikau on Sunday June 19, 2016 @07:59PM (#11935369)

> it competes with the fopen() system call

Nitpick: fopen() is not a syscall, it's part of stdio which is in libc (in user mode). The nearest POSIX syscall equivalent is open(2), but stdio does things like buffering and formatting in user mode on top. It's also more portable to non-Unix because stdio is in the C language spec.

I had heard this phrase before as simply "it competes with fopen()".

[ Parent | on HN ]