4 ms·

That's pretty surprising to hear, considering that SQLite is one of the most widely used pieces of software in existence and has a solid reputation. And the ins

by dpedu 6y ago

That's pretty surprising to hear, considering that SQLite is one of the most widely used pieces of software in existence and has a solid reputation. And the insane amount of testing they do - https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html.

3np 6y ago
I want to stress the (unfairly loosely defined) "these kinds of projects" there. There is nothing wrong with SQLite as such and in many situation it is perfect for the task. For a backend service that may need to scale, have availability requirements, is going to be run in a clustered or distributed environment, etc, it is not suitable. For one, you suddenly need to couple physical location of persisted data with usage of the same. Running it on networked filesystems is not supported. Yes, there are some caveats there and ways to work around it but it's a square-peg-round-hole kind of situation. For mobile or desktop apps, data jobs that can't be parallelized, local or light-weight analytics, embedded, it's great (though I do think many times it's used where something like leveldb or rocksdb would have been more appropriate but w/e). I'm sure there are other use-cases in both "great choice" and "terrible choice" I saw in the wild and can't recall. For something like gitea - it depends on the hosting environment,. requirements and scale. Obv for you it is not a pain-point, for me it absolutely is. --- I really appreciate when project give the user the choice, like they do here! ORMs are not the devil and can afford flexibility without having to spend time implementing for each supported backend specifically, if performance isn't critical enough that DB-specific optimizations are needed. IMO for a project that is going to be self-hosted by a wide range of users, it's often premature optimization to make the v1 tied to a specific DB.

by dpedu 6y ago

3np 6y ago

I want to stress the (unfairly loosely defined) "these kinds of projects" there. There is nothing wrong with SQLite as such and in many situation it is perfect for the task. For a backend service that may need to scale, have availability requirements, is going to be run in a clustered or distributed environment, etc, it is not suitable. For one, you suddenly need to couple physical location of persisted data with usage of the same. Running it on networked filesystems is not supported. Yes, there are some caveats there and ways to work around it but it's a square-peg-round-hole kind of situation. For mobile or desktop apps, data jobs that can't be parallelized, local or light-weight analytics, embedded, it's great (though I do think many times it's used where something like leveldb or rocksdb would have been more appropriate but w/e). I'm sure there are other use-cases in both "great choice" and "terrible choice" I saw in the wild and can't recall. For something like gitea - it depends on the hosting environment,. requirements and scale. Obv for you it is not a pain-point, for me it absolutely is. --- I really appreciate when project give the user the choice, like they do here! ORMs are not the devil and can afford flexibility without having to spend time implementing for each supported backend specifically, if performance isn't critical enough that DB-specific optimizations are needed. IMO for a project that is going to be self-hosted by a wide range of users, it's often premature optimization to make the v1 tied to a specific DB.