2 ms·

I’m on the contrary here; In my experience SQLite for these kinds of projects tend to become bottlenecks, failure points and/or corrupted eventually. As long a

by 3np 6y ago

I’m on the contrary here; In my experience SQLite for these kinds of projects tend to become bottlenecks, failure points and/or corrupted eventually. As long as I pushed it forward, setting up a decent Postgres cluster with failover that I use over local file systems when available has been great. I groan a bit anytime don’t thing requires persisting configuration to the local file system during the lifetime of the process. Backups are a lot smoother too. The time invested does come back pretty quick.

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 3np 6y ago

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.