This is a great pitch, and I don't want to come across as negative, but I feel like a statement …

I consider a "bug" to be "it was supposed to do something and failed". Issues around business logic are not failures of the system, the system worked to spec, the spec was not comprehensive enough and now we iterate.

I do think that it was a mistake to use the word "all" and imply that there are absolutely no bugs in FoundationDB. However, FoundationDB is truly known as having advanced the state of the art for testing practices: https://apple.github.io/foundationdb/testing.html . So in normal cases this would reek of someone being arrogant / overconfident, but here they really have gotten very close to zero bugs.

I think the reference to "all the bugs" here is basically that our insanely brutal deterministic testing system was not finding any more bugs after 100's of thousands of runs. Can't prove a negative obviously, but the fact that we'd gotten to that "all green" status gave us a ton of confidence to push forward in feature development, believing we were building on something solid - which, time has shown we were.

The best definition I've heard for "bug" is "software not working as documented". Of course, a lot of software is lacking documentation -- and those are doc bugs. But I like this definition because even when the docs are incomplete, the definition guides you to ask: would I really document that the software behaves like this or would I change the behavior [and document that]? It's harder (at least for me) to sweep goofy behavior under the rug.

To be fair, the line right after that is "I know, I know, that's an insane thing to say."

I feel like business logic bugs live on a separate layer, the application layer, and it's not fair to count those against the database itself. I agree that suboptimal query planning would be a database-layer bug, a defect which could easily be missed by the bug-testing framework.