> I feel like there must have been something else since 2016?
Funny, that was my feeling as well.
I'm 99% sure to have read a discussion on this here, but all submissions after 2016 (apart from today's) have no comments at all, hence also no comments linking to the older discussion.
Edit: Removed the remark on missing comments. The default search settings do not search for comments.
exactly, what's the mechanism by which this keeps getting posted individually (a time limit I assume)? it almost seems like marketing spam at this point.
The mechanism is simple: people keep running across it and finding it interesting. It's not spam, it's just the statistical cloud at work.
On HN, reposts are fine when a story hasn't had a significant thread in a year or so (see https://news.ycombinator.com/newsfaq.html). So it's certainly ok after 5 years! Though I'd swear we'd seen more threads than that...
Maybe a different marketing spam. I almost posted a video to Reddit last week that popped up on YouTube. It was an older video, by someone I’ve watched before, might have been one I’ve already seen, but there it was. I got distracted and didn’t. Three hours later, someone else posted it.
It could be pure coincidence, but more likely The Algorithm was trying to shake things up and sent fifty, a hundred, a thousand of us the same old url.
Why so? I have the impression every developer relies on it for a lot of local stuff, and many libraries also use it locally in users' machines for persistence needs.
I think they have this perspective because SQLite is almost never mentioned when DBs are discussed. Almost everyone pushes postgres, which I think is often a bit insane. Postgres or (often rarely) MySQL is given as the answer to most DB questions, even when coming from clearly new devs.
It's not often that the dev needs any of the large amount of setup/permissions required for postgres/MySQL. The fact that SQLite comes as part of python's standard library should be used as second nature for most devs.
I feel the same way - that SQLite should be the default answer, and one should reach towards postgres or MySQL unless you really *have* to.
Most of the answers I was referring to are miles away from those requirements. Postgres fanbois love to suggest it for everything - for which ahuge percentage of the time is simply 'This csv is too big, how do I load part of it?'.
The suggestion of Postgres is very often not required, because there isn't a need for multiple users, different permissions, password protection, etc.
SQLite is not meant to compete directly with MySQL or Postgres. It's meant for local usage only, where you don't need high concurrency, managing multiple connections, replication, etc.
I mean, you could probably use SQLite in many simple cases which currently use Postgres (personal servers, small apps), but advocating it as default solution is inadequate at best, if not misleading to people starting out in the field.
This view is the view I was talking about in the op.
Inadequate for what? Most persistence layers I've ever seen did not need MySQL, postgres or MongoDB.
> high concurrency, managing multiple connections, replication
In the grand scheme of things, basically nobody needs these things. Sorry, your app is overengineered.
Your app actually suffered in areas such as performance, security, portability, complexity and cost.
Developers love to prematurely optimise everything. Most SaaS products today don't need a dedicated database server. Most apps that require a database server backend would be better with sqlite, most Dev/test/staging/prod pipelines would be better served with sqlite files.
> but don't need clustering or failover strategies.
Even for those cases where you do need it, there are emerging options. You can handle replication 100% in business logic (something I personally enjoy), or you can use a path like dqlite to replicate the physical WAL log.
SQLite is a file format with a SQL engine which makes it a great embedded database.
It is not an RDBMS in the true sense so in my opinion it is correctly rated.
I tried using SQLite to solve problems which normally would require an RDBMS and ran into so many issues like the lack of enforced static types, built in date or decimal types (and fast aggregations on dates), concurrent writes, etc. It’s only when you’ve gone through this process that you’ll realize that SQLite it not the database you think it is — and SQLite itself is up front about that: https://www.sqlite.org/aff_short.html
> the SQLite library consists of approximately 143.4 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 640 times as much test code and test scripts - 91911.0 KSLOC.
How does SQLite compare for bugs in comparison to other DBs? How much are the other players paying out in bug bounties?
I remember reading someone here explain the extensive number of tests the oracle database has and how implementing a feature is more of a waiting for tests to fail game rather than writing code. I couldn't find it now, maybe I'm misremembering.
Especially after reading the MySQL post yesterday[0], I don't know what to expect anymore.
Does anyone have anything to say about the testing story of Postgres?
A lot of the mentioned tools are fuzzers[1], these are tools that start from certain input(s), say "SELECT * FROM TABLE WHERE some_column = some_value", and repeatedly
1- mutates[2] the input,
2- measures some metric of the database's performance (e.g. how many non-syntax errors it spat out)
3- and introduces more or less mutations to increase or decrease that metric.
In short, an evolutionary computation where the population being generated is test code, the fitness function is some metric summarizing how the generated test code tested the db code, and mutation operators gradually pushes the generated test code towards a certain optima that we want our tests to have.
This is an extremely general approach that can be used to generate anything, and it's uncannily effective at finding bugs especially in structured-format consumers like compilers[3] and db engines. You can use it to generate queries as above and the fitness function would be something like "Did the database gave an unholy error squeak or violate some key invariants in the db file?", you can use it to generate general test harnesses that exercise the whole C code and measure coverage via instrumentation, the fitness function would be something like "How much did this mutation covered of the application's instructions?". Not only do they take both of those approaches and many others, but they do it multuple times and independently, so for example it's mentioned that Google and the core development team both have an independent query fuzzer. They mention about 4 or 5 fuzzers doing similar thing.
And off course fuzzing is just one way to generate tests, there are plenty others.
>I strongly doubt it’s all actually source code
I mean, why not? source code is not necessarily hand-written source code.
[2]: Generally, mutation is either completely blind and general, i.e. byte-level , or structure-aware, i.e. has some notion of a grammar or a schema governing the thing it mutates, it wouldn't just change a random letter of "SELECT", because the result would almost cerainly be invalid SQL.
Maybe. But we learn from the sheer hard work put into this level of testing. And having this level of testing makes you put a bit more effort into each new line.
The bar has been raised. If someone is to make a better embedded DB, they will have to maintain it at least as well as this.
(PS I feel embarrassed by my own testing failures when reading this).
A large amount of the testing is performed by their proprietary test harness.
> TH3 consists of about 71.5 MB or 978.3 KSLOC of C code implementing 46622 distinct test cases. TH3 tests are heavily parameterized, though, so a full-coverage test runs about 1.9 million different test instances. The cases that provide 100% branch test coverage [of SQLite] constitute a subset of the total TH3 test suite. [1]
> SQLite itself is in the public domain and can be used for any purpose. But TH3 is proprietary and requires a license.
> Even though open-source users do not have direct access to TH3, all users of SQLite benefit from TH3 indirectly since each version of SQLite is validated running TH3 on multiple platforms (Linux, Windows, WinRT, Mac, OpenBSD) prior to release. So anyone using an official release of SQLite can deploy their application with the confidence of knowing that it has been tested using TH3. They simply cannot rerun those tests themselves without purchasing a TH3 license. [2]
It's a great business decision. My understanding is that SQLite's big consulting income comes when some company somewhere produces a new piece of embedded hardware and needs SQLite to work on it. They can work directly with the company to get that to happen, using the company's proprietary testing suite.
I use sqlite every day at work as a web dev. I do a lot of work with file uploaders and being able to import CSV files as tables I can query is a killer feature.
In SQlite's source code, it has the following comment.
2001 September 15
The author disclaims copyright to this source code. In place of a legal notice, here is a blessing:
- May you do good and not evil.
- May you find forgiveness for yourself and forgive others.
- May you share freely, never taking more than you give.
SQLite is _the_ most amazing database in my opinion. (Not the most amazing distributed database for obvious reasons). It strips away all the connect and network IO management, and focuses on the actual database. It's _the_ most deployed and used database in the world (it's even running outside of the Earth). Because of its wide distribution, it has to be very well tested. It's much harder to fix a bug on client (comparing to on server).
Dr. Hipp is amazing. I wish more people are like him.
>> the project has 640 times as much test code and test scripts - 91911.0 KSLOC.
This is amazing. One of the reasons some of the developers don’t write extensive test code is because it can cause delays in the deliverables and miss deadlines. How is the sqlite team able to write such a large number of test cases and not miss deadlines?
One reason I suspect is that it's a well defined product. The "spec" is quite well specified at this point. When changes are made existing tests just need to catch regressions, not be changed extensively due to changed meaning of existing primitives. Projects with significant spec/feature churn can't do the same.
SQLite doesn’t really have market pressure, so they can choose any deadline such that it provides adequate time for writing test code — assuming they set deadlines at all.
One thing I was kind of surprised about while reading through this massively humbling post: if there’s a bit flip in a value in a closed DB the value just changes?
Like, there’s no checksum or error correction in an SQLite DB?
That's fairly normal for database systems. E.g. in postgres it's also an optional thing that needs to be enabled, and afaik MySQL doesn't have it either (it has an explicit "calculate a checksum for this data" command, which e.g. can be used to verify replication or backups, but no live checksumming)
50 comments
[ 3.4 ms ] story [ 104 ms ] threadhttps://hn.algolia.com/?q=how+sqlite+is+tested
How SQLite Is Tested - https://news.ycombinator.com/item?id=11936435 - June 2016 (57 comments)
How SQLite Is Tested - https://news.ycombinator.com/item?id=9737754 - June 2015 (1 comment)
How SQLite Is Tested - https://news.ycombinator.com/item?id=9095836 - Feb 2015 (17 comments)
How SQLite is tested - https://news.ycombinator.com/item?id=6815321 - Nov 2013 (37 comments)
How SQLite is tested - https://news.ycombinator.com/item?id=4799878 - Nov 2012 (6 comments)
How SQLite is tested - https://news.ycombinator.com/item?id=4616548 - Oct 2012 (40 comments)
How SQLite Is Tested - https://news.ycombinator.com/item?id=633151 - May 2009 (28 comments)
Funny, that was my feeling as well.
I'm 99% sure to have read a discussion on this here, but all submissions after 2016 (apart from today's) have no comments at all, hence also no comments linking to the older discussion.
Edit: Removed the remark on missing comments. The default search settings do not search for comments.
On HN, reposts are fine when a story hasn't had a significant thread in a year or so (see https://news.ycombinator.com/newsfaq.html). So it's certainly ok after 5 years! Though I'd swear we'd seen more threads than that...
It could be pure coincidence, but more likely The Algorithm was trying to shake things up and sent fifty, a hundred, a thousand of us the same old url.
I know it's popular, but nowhere near to the level it should be.
So, like, even more popular than that?!
https://www.sqlite.org/mostdeployed.html
What do you think it "should be" and is missing?
The suggestion of Postgres is very often not required, because there isn't a need for multiple users, different permissions, password protection, etc.
I mean, you could probably use SQLite in many simple cases which currently use Postgres (personal servers, small apps), but advocating it as default solution is inadequate at best, if not misleading to people starting out in the field.
Inadequate for what? Most persistence layers I've ever seen did not need MySQL, postgres or MongoDB.
> high concurrency, managing multiple connections, replication
In the grand scheme of things, basically nobody needs these things. Sorry, your app is overengineered.
Your app actually suffered in areas such as performance, security, portability, complexity and cost.
Developers love to prematurely optimise everything. Most SaaS products today don't need a dedicated database server. Most apps that require a database server backend would be better with sqlite, most Dev/test/staging/prod pipelines would be better served with sqlite files.
I get the impression that it's used exactly as it should be, in systems that need a database but don't need clustering or failover strategies.
Even for those cases where you do need it, there are emerging options. You can handle replication 100% in business logic (something I personally enjoy), or you can use a path like dqlite to replicate the physical WAL log.
It is not an RDBMS in the true sense so in my opinion it is correctly rated.
I tried using SQLite to solve problems which normally would require an RDBMS and ran into so many issues like the lack of enforced static types, built in date or decimal types (and fast aggregations on dates), concurrent writes, etc. It’s only when you’ve gone through this process that you’ll realize that SQLite it not the database you think it is — and SQLite itself is up front about that: https://www.sqlite.org/aff_short.html
> the SQLite library consists of approximately 143.4 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 640 times as much test code and test scripts - 91911.0 KSLOC.
How does SQLite compare for bugs in comparison to other DBs? How much are the other players paying out in bug bounties?
https://corecursive.com/066-sqlite-with-richard-hipp/
Especially after reading the MySQL post yesterday[0], I don't know what to expect anymore.
Does anyone have anything to say about the testing story of Postgres?
[0]: https://news.ycombinator.com/item?id=29455852
edit: found it https://news.ycombinator.com/item?id=18442941
That seems ridiculous to me. I can’t imagine what would lead to so many lines, but I strongly doubt it’s all actually source code.
1- mutates[2] the input,
2- measures some metric of the database's performance (e.g. how many non-syntax errors it spat out)
3- and introduces more or less mutations to increase or decrease that metric.
In short, an evolutionary computation where the population being generated is test code, the fitness function is some metric summarizing how the generated test code tested the db code, and mutation operators gradually pushes the generated test code towards a certain optima that we want our tests to have.
This is an extremely general approach that can be used to generate anything, and it's uncannily effective at finding bugs especially in structured-format consumers like compilers[3] and db engines. You can use it to generate queries as above and the fitness function would be something like "Did the database gave an unholy error squeak or violate some key invariants in the db file?", you can use it to generate general test harnesses that exercise the whole C code and measure coverage via instrumentation, the fitness function would be something like "How much did this mutation covered of the application's instructions?". Not only do they take both of those approaches and many others, but they do it multuple times and independently, so for example it's mentioned that Google and the core development team both have an independent query fuzzer. They mention about 4 or 5 fuzzers doing similar thing.
And off course fuzzing is just one way to generate tests, there are plenty others.
>I strongly doubt it’s all actually source code
I mean, why not? source code is not necessarily hand-written source code.
[1]: skim https://www.fuzzingbook.org/ for a fairly good overview
[2]: Generally, mutation is either completely blind and general, i.e. byte-level , or structure-aware, i.e. has some notion of a grammar or a schema governing the thing it mutates, it wouldn't just change a random letter of "SELECT", because the result would almost cerainly be invalid SQL.
[3]: https://embed.cs.utah.edu/csmith/
The bar has been raised. If someone is to make a better embedded DB, they will have to maintain it at least as well as this.
(PS I feel embarrassed by my own testing failures when reading this).
> TH3 consists of about 71.5 MB or 978.3 KSLOC of C code implementing 46622 distinct test cases. TH3 tests are heavily parameterized, though, so a full-coverage test runs about 1.9 million different test instances. The cases that provide 100% branch test coverage [of SQLite] constitute a subset of the total TH3 test suite. [1]
> SQLite itself is in the public domain and can be used for any purpose. But TH3 is proprietary and requires a license.
> Even though open-source users do not have direct access to TH3, all users of SQLite benefit from TH3 indirectly since each version of SQLite is validated running TH3 on multiple platforms (Linux, Windows, WinRT, Mac, OpenBSD) prior to release. So anyone using an official release of SQLite can deploy their application with the confidence of knowing that it has been tested using TH3. They simply cannot rerun those tests themselves without purchasing a TH3 license. [2]
[1] https://sqlite.org/testing.html
[2] https://sqlite.org/th3.html
https://sqlite.org/prosupport.html
2001 September 15
The author disclaims copyright to this source code. In place of a legal notice, here is a blessing:
- May you do good and not evil.
- May you find forgiveness for yourself and forgive others.
- May you share freely, never taking more than you give.
SQLite is _the_ most amazing database in my opinion. (Not the most amazing distributed database for obvious reasons). It strips away all the connect and network IO management, and focuses on the actual database. It's _the_ most deployed and used database in the world (it's even running outside of the Earth). Because of its wide distribution, it has to be very well tested. It's much harder to fix a bug on client (comparing to on server).
Dr. Hipp is amazing. I wish more people are like him.
This is amazing. One of the reasons some of the developers don’t write extensive test code is because it can cause delays in the deliverables and miss deadlines. How is the sqlite team able to write such a large number of test cases and not miss deadlines?
SQLite doesn’t really have market pressure, so they can choose any deadline such that it provides adequate time for writing test code — assuming they set deadlines at all.
Like, there’s no checksum or error correction in an SQLite DB?