dbdb.io: a catalogue of database systems you can filter by feature

What the catalogue actually records

The Database of Databases is an on-line database of databases, and the project description is short. What the data model holds is visible from the fixture documentation, and it is more specific than a directory of links.

There is a Feature model and a FeatureOption model, an Attribute model and an AttributeOption model, and systems. The features and attributes are the axes the catalogue filters on, and the options are the values each system takes for them. The fixture documentation also mentions saved searches, which is a sign that the site lets a user keep a filtered view.

The modelling is the interesting part. Separating a feature from its options means a system can be recorded as supporting a feature with a particular option, so the questions a developer actually asks, does this database do multi-master, does it do time series, is it embeddable, does it have a relational model with secondary indexes, can it be used as a distributed SQL database, are each rows in a table rather than a paragraph of prose in a wiki page.

That structure is why the site can be filtered at all, and it is also what makes it maintainable. Adding a database means adding rows and options, not writing an article, which is a different and much cheaper kind of contribution.

The project comes from the cmu-db organisation, and it is written in Python with Django 6.0.8 as the framework version, pinned exactly in the dependency list. The application version in the project metadata is 2.0.0, and the licence is Apache-2.0. The last push to the repository was on 2026-10-20, and the project publishes no GitHub releases.

A Django app with a documented local setup

The repository is a conventional Django project, and the readme documents the local workflow in enough detail to be useful.

The installation step installs the system packages and then syncs the Python environment with uv:

sudo apt-get install build-essential libffi-dev libpq-dev python3-dev postgresql-common-dev libcairo2
uv sync

Those packages are not arbitrary. libpq-dev and postgresql-common-dev are for the PostgreSQL driver, python3-dev for building Python packages, and libcairo2 with the cairocffi and cairosvg dependencies points at the site's use of Cairo for rendering, which is consistent with a catalogue that displays logos and diagrams.

The development server is a single command:

uv run python manage.py runserver

And deployment is a shell script rather than a container or a PaaS configuration. The readme says to run deploy/update_dbdb_app.sh on the production machine to fetch new changes, run migrations, and restart the wsgi server. gunicorn is the pinned WSGI server in the requirements.

The Python requirement is 3.13 or newer, declared in the project metadata, and there is a .python-version file at the root alongside a uv.lock, which means the environment is reproducible. The requirement lists are split into requirements.txt, requirements-dev.txt and requirements-test.txt, with the project file also pinning versions directly.

Fixtures, and the part of them that comes from production

The test fixtures section is the most revealing part of the readme, because it shows how the catalogue's data is tested and where the boundary between synthetic and real data sits.

The fixtures live in data/fixtures/, and Django loads them by name with the search path configured in settings.py through FIXTURE_DIRS. The table lists six of them. adminuser.json is a static superuser account for tests, testuser.json is a static non-superuser account. core_system.json is static and holds two synthetic test systems, SQLite and one labelled XXX. core_savedsearch.json is static and holds one saved search. Then there are two that are not static: core_features.json, holding Feature and FeatureOption rows, and core_attributes.json, holding Attribute and AttributeOption rows, both dumped from production.

The reason for the split is practical. The feature and attribute vocabularies are the part of the catalogue that every entry depends on, and a test that used a hand-written subset of them would pass while the real thing was broken. Dumping those from production keeps the test data faithful to what the site actually ships. The systems themselves stay synthetic, because a real system entry drags in licensing details and version history that would make the fixture unstable.

Regenerating the two production-derived fixtures requires Tailscale to be connected so that the internal hostname is reachable, and the commands are ordinary Django data management:

# Features and feature options
uv run python manage.py dumpdata core.feature core.featureoption \
    --indent 2 -o data/fixtures/core_features.json

# Attributes and attribute options
uv run python manage.py dumpdata core.attribute core.attributeoption \
    --indent 2 -o data/fixtures/core_attributes.json

And the readme is explicit that these commands use the DATABASE_URL in .env, which points at the production database. That is a detail worth pausing on for anyone planning to work on this project: running the documented regeneration command against your own environment writes a file that has just been exported from whatever database your .env points at, and the intended target is production.

The test suite needs a local PostgreSQL and rebuilds its database every run

The tests require a local PostgreSQL instance, and the runner creates and destroys a dedicated database named test_dbdb_io on every run.

The command takes the settings module explicitly and asks for verbose output:

PGUSER=<your-local-pg-user> uv run python manage.py test dbdb.core \
    --settings=dbdb.test_settings --verbosity=2

The dbdb.test_settings module overrides the production DATABASE_URL with local PostgreSQL connection parameters, and it reads a set of environment variables that are all optional, with defaults shown in the readme.

PGUSER defaults to dbdb_user and must have the CREATEDB privilege, since the runner needs to create and drop the test database. PGPASSWORD defaults to empty, and the note says to omit it when using peer authentication over a Unix socket. PGHOST defaults to empty, and the distinction matters: an empty value means a Unix socket with peer auth, while localhost means TCP. PGPORT defaults to 5432 and PGDATABASE defaults to postgres, with the requirement that the connection database must differ from test_dbdb_io.

The fact that the test database is always named test_dbdb_io and is dropped and recreated fresh on every run is the safety property here. The test suite cannot leave stale state behind, and it cannot accidentally touch the connection database, because the two are required to be different names.

The application code is tested through a module path, dbdb.core, which suggests the test suite is organised around the core app rather than the whole project, which is a reasonable scope for a Django site whose interesting logic is in the catalogue models and the filter views.

Where dbdb.io is the wrong tool

The first limitation is that it is a catalogue and not a benchmark. There are no performance numbers, no measurements on your hardware, no comparison of how a system behaves under your workload. The value is in the feature and licence metadata, which tells you what a system implements and what it costs, and a team that then has to benchmark the three finalists itself.

The second is that the data is maintained by hand. The fixture documentation shows the vocabulary being dumped from production and loaded into tests, and nothing in the readme describes a crawler or an automatic import from vendor documentation. That means the catalogue is as current as the last time somebody edited it, and for a system that shipped a new major version last week the entry may still describe the old one. A team that needs a fresh answer for a specific product has to check the vendor's own documentation as well.

The third is the scope of the model. Saved searches appear in the fixture table and a set of features and attributes, and the site's own navigation for a given system is a set of pages. What it does not offer is a data export in the shape a procurement process wants, beyond the API that the site already exposes for its own front end. A team that wants the catalogue inside its own evaluation spreadsheet is using the API, and that is a supported path, but it is work.

The fourth is the toolchain weight for a contributor. The local setup needs PostgreSQL, the uv toolchain, Python 3.13, and a set of system packages including Cairo, and the test run needs a PostgreSQL user with CREATEDB. For a project whose own tests need a real database rather than a container or an embedded substitute, the barrier to a first contribution is real.

The fifth is the AI tooling in the dependency list, which deserves a note rather than a judgement. The pinned requirements include anthropic, openai and ollama, plus playwright, selenium and scikit-learn. Whatever the site is doing with those, none of it is described in the readme, so a reader cannot tell from the documentation what part of the catalogue is generated and what part is curated.

Editorial conclusion

dbdb.io fits a developer who has to choose a database and wants the criteria separated from the marketing, since the catalogue records versions, licences and feature support for each system rather than performance, and the filter set is drawn from what the systems actually implement. It is the wrong choice if you need benchmark numbers or a head-to-head comparison on your own workload, since the site is a catalogue and not a test harness, and it is the wrong choice if you need a machine-readable feed beyond the API it already exposes. Before relying on it, note that the data is maintained by the project rather than scraped automatically, so check the entry for the system you care about, and note that the last push was on 2026-10-20 with the project at version 2.0.0 and Django 6.0.8.

Frequently asked questions

Official sources

1. cmu-db/dbdb.io on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README