Designing Bugzilla for Multi‑Database Support: A Case Study

Bugzilla originally stored all its data in a single database system called OldDB, which limited customers to that platform.

New customers began requesting support for a different database, NewDB, because they were already familiar with it, while existing customers still preferred OldDB.

To accommodate both groups, Bugzilla needed to add multi‑database support, a change that required extensive code modifications because the existing codebase lacked a centralized data‑access layer and contained many OldDB‑specific commands.

One naive approach would be to sprinkle conditional if statements throughout the code, but that would roughly double the code’s complexity, making it unmaintainable for the part‑time developers on the Bugzilla team.

Consequently, the team decided to redesign the system so that it could easily support multiple databases, a substantial engineering effort for the small team.

Modify all code that can use standard database commands. Identify places where generic commands work across databases and replace OldDB‑specific calls with these standard commands.

Create wrapper functions for non‑standard commands. For each database‑specific command, write a function that returns the appropriate command for the current database, then replace direct calls with these functions.

Replace OldDB‑specific designs with standard functionality. Eliminate features that exist only in OldDB, substituting them with universally supported alternatives, possibly in incremental steps.

Redesign Bugzilla’s installation system. Simplify the installer and extend it to configure both OldDB and NewDB (and eventually other databases).

Each of these high‑level tasks is itself a project, further broken down into smaller, well‑designed steps that can be individually tested.

After any change, the system is tested to ensure that its behavior on OldDB remains unchanged.

The result is not a perfect system, but it is a significantly better one: Bugzilla now supports four different database systems, and the codebase is easier to maintain.

Key take‑aways from the story:

Break a large task into many smaller tasks.

Smaller tasks lead to a better‑designed system.

Each small task is essentially a mini‑project.

After each mini‑project, verify that the system still works correctly.

The article originates from Google’s Code Health group, written by Max Kanat‑Alexander in the booklet “code Simplicity.”