Why SQLite3?

There have been some questions about why BIND 10's first milestone release only supports SQLite3 for storing zone information. I hope I can answer some of the questions by explaining how and why we came to this decision.

Part of the decision was a simple matter of time. We knew we would only have resources to implement a single data store. We ended up implementing two, but one is a trivial one: authors.bind and other static zone content.

That explains why we chose to implement only one, but why was it SQLite3?

BIND 9, which we are improving on here, has a rock-solid in-memory database implementation. When BIND 9 was written, this database was our only working data store, which tended to cause us to come to expect its behavior. For example, some things that are very easy to do when you have all the data at hand are very hard to do efficiently when you must search for the answer. When we ran into the need for some special attribute of a stored name or data, we would just add it.

This soft of thinking made our code very dependent on the characteristics and behavior of our in-memory database implementation. Worse, it blurred the boundary between the application code and the database in many ways, since if we didn't like what it did, we could just change it. We controlled both sides of the API.

We have had many users requesting that BIND 9 perform SQL or LDAP queries for authoritative data. There are some contributed code for SQL, but it is extremely inefficient as there is no caching of answers. It also uses an additional layer between the full-on BIND 9 Database API, called the "sdb" or "simple database" API. Simple here is a relative term.

We did not want this sort of thinking to happen in BIND 10. We knew from the start that we could do an in-memory database, but the SQL beast was a new thing for us. It has many possible ways it can be used: Can we write to the database? Does it have necessary ordering capability for DNSSEC? How long should we cache query results for, if at all? What does the schema look like?

After all those questions are answered in SQL terms, the design and implementation of an in-memory database looks like a walk in the park. This was the compelling reason to choose SQL.

Once we decided to do SQL first, SQLite3 was the logical choice. It requires no server, no license, and has a very easy to use API. It is fairly fast, and has language bindings for pretty much every modern language out there. In short, it was a painless way to get SQL without making it hard on those trying out our release.

I hope this helps explain some of what we thought about before deciding on an SQL back end for the first-year release. We fully intend to implement in-memory, non-SQL on-disk, and many SQL variants before the project is done.