So I pretty much exclusively use SQLite, just wondering when you would use a different option? Is it all personal preference, depends on the scope of the project, ease of use...? How do you decide what you're going to use when you start a (say small) project?
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
So I pretty much exclusively use SQLite, just wondering when you would use a different option? Is it all personal preference, depends on the scope of the project, ease of use...? How do you decide what you're going to use when you start a (say small) project?
Unless I actually need some functionality that's provided by having an SQL interface, I try to avoid it. I have no issue 'speaking' basic SQL, it's just that in most cases, you don't actually need it, so ti largely just adds overhead (SQL is complicated from an implementation perspective). See for example all of the major FOSS web browsers historically using SQLite for their cache, when all they really need is flat files with directory hashing and a simple 1:1 index.
Other disadvantages to SQLite specifically include it not being truly concurrent-access safe, and reimplementing much of the work the underlying filesystem is already doing.
Personally, if it's just simple data serialization, I'm a fan of YAML. It's reasonably lightweight, easily extensible, widely supported, and most importantly, can be debugged even by non-programmers. It does, of course, have it's own issues, but most of them are non-issues for my typical usage.
If you plan on having more than one process needing to make database calls or if you're expecting periods of very high traffic*.
SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites). The amount of web traffic that SQLite can handle depends on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.
So I pretty much exclusively use SQLite, just wondering when you would use a different option? Is it all personal preference, depends on the scope of the project, ease of use...? How do you decide what you're going to use when you start a (say small) project?
Unless I actually need some functionality that's provided by having an SQL interface, I try to avoid it. I have no issue 'speaking' basic SQL, it's just that in most cases, you don't actually need it, so ti largely just adds overhead (SQL is complicated from an implementation perspective). See for example all of the major FOSS web browsers historically using SQLite for their cache, when all they really need is flat files with directory hashing and a simple 1:1 index.
Other disadvantages to SQLite specifically include it not being truly concurrent-access safe, and reimplementing much of the work the underlying filesystem is already doing.
Personally, if it's just simple data serialization, I'm a fan of YAML. It's reasonably lightweight, easily extensible, widely supported, and most importantly, can be debugged even by non-programmers. It does, of course, have it's own issues, but most of them are non-issues for my typical usage.
If you plan on having more than one process needing to make database calls or if you're expecting periods of very high traffic*.
More info here.