# OpenModelDB: a community catalogue of AI upscaling models with comparable previews > OpenModelDB is a React and Next.js site that catalogues more than six hundred AI upscaling models with metadata, example images and architecture information, so you can filter by architecture, scale or tags and compare two models side by side before downloading one. The catalogue lives as files in a data/models directory, and the site is generated statically. **OpenModelDB/open-model-database** — An open and free database for AI models - Repository: https://github.com/OpenModelDB/open-model-database - Website: https://openmodeldb.info - Stars: 558 · Forks: 65 - Language: TypeScript - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/openmodeldb-open-model-database ## A catalogue of upscaling models, with the models themselves hosted elsewhere OpenModelDB is a community-driven database of AI upscaling models. The description in the README is precise about what that means: a centralized place to discover, compare, and download image and video upscaling models with detailed metadata, example images, and architecture information. The word download there refers to the models, not to the database. The feature list says download models from various sources, and the site links out rather than hosting weights. That distinction is the most important thing to understand before you look at the repository, because it decides what kind of project this is. This is a catalogue, in the sense that a library catalogue is a catalogue. The value is in the metadata and the comparison, not in the artefacts. The scale is stated as browse 600+ AI upscaling models with detailed information. The README also carries a badge that counts the files in the data/models directory of the GitHub repository, which is a nice touch: the number of models is visible in the badge rather than asserted in prose, so it stays honest as the catalogue grows. The comparison feature is the one that distinguishes it from a list of links. The README describes comparing models side-by-side with example images, and the dependency list includes react-compare-slider, which is the component that does the drag-and-side-by-side comparison. So the site is built around the idea that you look at the same source image processed by two models and judge for yourself, rather than reading a benchmark table. The filtering is by architecture, scale, tags, and more, and the metadata view covers training details and licenses. The licence field is the one to pay attention to, and it is per-model: the catalogue records what the upstream model is licensed under, which is the only sensible approach for a catalogue aggregating other people's work. The homepage is openmodeldb.info, the primary language is TypeScript, and the licence is GPL-3.0. The last push was on 2026-08-14 and there are no GitHub releases. ## The catalogue is a directory of files, and the site is generated from it The repository layout is what makes this project tractable, and it is worth reading because the data model is visible in the file tree rather than hidden behind a database. There is a data/ directory at the root, with the models inside data/models, and the badge in the README counts the files in that directory by extension. Then there is src/ for the application, scripts/ for the tooling, public/ for static assets, docs/ for the documentation, and tests/. Alongside those are the usual project files: next.config.js, tailwind.config.js, postcss.config.js, tsconfig.json, pyrightconfig.json, an .eslintrc.js, a .stylelintrc.json, a .storybook/ directory, a .vscode/ directory, and a vitest.config.ts. The presence of a .storybook directory tells you the UI components are developed in isolation with Storybook, which is what a site with a comparison UI and many small components would want. The scripts directory is the part that matters for understanding how the catalogue is produced. The package.json gives every one of them a named entry point. ```json "validate-db": "ts-node --project scripts/tsconfig.json scripts/validate-db.ts", "fix-db": "ts-node --project scripts/tsconfig.json scripts/validate-db.ts -- --fix", "detect-broken": "ts-node --project scripts/tsconfig.json scripts/broken.ts", "generate-api": "ts-node --project scripts/tsconfig.json scripts/generate-api.ts", "generate-thumbnails": "ts-node --project scripts/tsconfig.json scripts/generate-thumbnails.ts", "download-images": "ts-node --project scripts/tsconfig.json scripts/download-images.ts" ``` So there is a validator that can also fix, a broken-link detector, an API generator, a thumbnail generator and an image downloader. That is a proper data pipeline rather than a hand-maintained list. The validate-db and fix-db pair is the interesting one. validate-db reports problems and fix-db runs the same script with a --fix flag, which means the same code path validates and repairs. A script that rewrites the catalogue automatically is worth being careful with, but having one implementation serve both roles avoids the classic problem of a fixer and a validator disagreeing about what is correct. The generate-api script is what makes the API available, and the key detail is in the build script. ```json "build": "npm run generate-thumbnails && cross-env NEXT_OUTPUT_EXPORT=true next build && npm run generate-api && npm run fix-db" ``` The API is generated during the build, from the same data files the site reads, so the API and the site cannot drift apart. The NEXT_OUTPUT_EXPORT flag turns the Next.js build into a static export, and the order is deliberate: thumbnails first, then the build, then the API, then the database fixup. ## Getting it running is three commands, and the port is fixed in the scripts The Getting Started section is the shortest in the README, which is what you would expect from a Next.js project. The prerequisites are Git and Node.js 18.17.0 or newer, and the engines field in the package.json says the same, node >=18.17.0. ```bash # Clone the repository git clone https://github.com/OpenModelDB/open-model-database.git cd open-model-database # Install dependencies npm ci # Start the development server npm run dev ``` npm ci rather than npm install, which is the right choice for a repository with a committed package-lock.json because it installs exactly the locked versions and fails if the lockfile is out of sync with the manifest. The dev script is next dev -p 3010, so the port is set in the script rather than left to the default of 3000. That matters because the README tells you the site will be available at http://localhost:3010, and if the port were configurable you would have a mismatch between the documentation and the actual behaviour. The same port appears in the Storybook script, storybook dev -p 6006, so component development happens on its own port and does not collide with the site. The lint story is worth noting because it has three variants and the differences are meaningful. The lint script runs eslint over the JavaScript and TypeScript sources and stylelint over the styles. lint:fix does the same with the fix flags. And lint:ci adds --max-warnings 0, so any warning fails the check. That is the strict variant used in CI, and it is why the local lint and the CI lint can disagree about a file that is merely untidy. The test script is vitest run, with test:watch for the interactive variant. There is a separate storybook build script for producing the static component catalogue. So the contributor loop is: npm run dev for the site, npm run storybook for components in isolation, npm run test for the unit tests, and npm run lint for style. Nothing in that loop requires the pipeline scripts, which is a sensible split between working on the interface and working on the data. ## A Python helper sits next to the TypeScript pipeline There is a file in the repository root called invoke-spandrel.py, and it is the one piece of Python in an otherwise TypeScript project. Spandrel is the library that gives a uniform interface over a wide range of neural network upscaling architectures, so this script is almost certainly the piece that loads a model and produces the comparison images. That single file tells you something important about the pipeline. The website, the API generation and the data validation are all TypeScript, but the model inference is Python. Those are different runtimes with different dependency trees, and the reason for the split is that the upscaling model ecosystem lives in Python while the catalogue and its presentation want a TypeScript toolchain. The Python helper therefore sits outside the npm scripts, which is why the package.json scripts list has nothing for it. It is invoked separately, by whoever is adding a model, to generate the example images and thumbnails that the comparison view needs. This is a sensible architecture for the problem, and it has an operational consequence. A contributor adding a model needs a working Python environment with the inference dependencies, in addition to Node. That is a heavier setup than a pure content contribution, and it is the reason the Contributing Guide on the site is worth reading before you start. The contributing routes the README lists are also telling. You can add new AI upscaling models to the database, report bugs by opening an issue, suggest features, and improve the documentation. The guide then details how to add models via the web interface, set up a local development environment, and submit pull requests. The web interface route matters for the scale of the catalogue. Six hundred models is well past the point where a maintainer could add them by hand, and the fact that there is a form-based path alongside the command line path suggests the data is expected to arrive from many people who are not running the local toolchain. There is a Discord for discussion, and the FAQ and website are linked from the README. The project also carries a static badge for PRs welcome and a GitHub workflow status badge for the frontend, so the CI signal for the site is visible from the repository page. ## Where OpenModelDB is the wrong tool The first wrong-tool case is a project that needs the models themselves in one place. The site links to the various sources each model is downloaded from, which means a pipeline that wants every model locally is still assembling a download list by hand and resolving the sources individually. The catalogue does not solve distribution. The second case is a team that needs a stable programmatic API over time. The API is generated at build time from the data files, which is exactly right for keeping the API and the site consistent, and exactly wrong for a client that wants a versioned contract. There is no published schema, no version field and no changelog for the API in the visible documentation, so a client cannot tell whether a field was added, renamed or removed between builds. The third case is a team that needs a licence clearance workflow. The catalogue records the licence of each model, which is genuinely useful information, but it is metadata, not enforcement. If you need to know that every model you ship is under a licence your organisation accepts, you still need to check each entry, and the fact that the field is a string in a data file rather than a controlled vocabulary means the values are whatever the contributor typed. There is also a data freshness consideration. The images and thumbnails are generated by running models, and the catalogue holds the results rather than the models. If a model is re-released with different weights under the same name, the entry does not change on its own, and the detect-broken script checks for broken things rather than for stale content. The last point to check before adopting is the licence of the site code against the licence of the catalogue. The project is GPL-3.0, which is a copyleft licence, and the models it catalogues carry their own licences which range across permissive and non-commercial terms. A site under GPL-3.0 that links to and describes other projects is fine, but if you were to take the data files and redistribute them as your own dataset, the GPL-3.0 terms of the database would apply to that redistribution. For a catalogue meant to be read and linked to, that is the right arrangement, and for anything more, it is a question for your licence reviewer. What the project gives you is a way to narrow six hundred candidates down to a handful without downloading any of them, using example images from the same source, the architecture and scale filters, and the training details and licence per entry. That is a real saving, and the fact that the data is plain files in a repository means you can also clone it and query it with whatever you like. ## Conclusion OpenModelDB suits a person choosing an upscaling model for their own pipeline, because the catalogue gives you side-by-side example images, training details and licence information per model rather than a list of download links, and the entries are plain files you can read without running anything. It does not suit a project that needs the models themselves, since the site links to the various sources they are downloaded from rather than hosting weights, and it does not suit a team that needs a stable API, since the API is generated at build time from the same data files. Before adopting, read a few entries in data/models and check the licence field on each one, because the catalogue records the upstream licence rather than applying one of its own. ## FAQ ### What is OpenModelDB? OpenModelDB is a community-driven database of AI upscaling models, providing a centralized place to discover, compare, and download image and video upscaling models with detailed metadata, example images, and architecture information. The site is at openmodeldb.info. ### How do I run OpenModelDB locally? Clone the repository, run npm ci to install dependencies, then npm run dev. The dev script runs next dev -p 3010, so the site is available at http://localhost:3010. You need Git and Node.js 18.17.0 or newer. ### How are the models stored in OpenModelDB? They are stored as files in the data/models directory of the repository, one file per model, which is why the README can show a live file count badge for that directory. The scripts validate-db, fix-db, detect-broken, generate-api and generate-thumbnails operate on those files. ### How do I compare two models in OpenModelDB? The site compares models side-by-side with example images, using the react-compare-slider component in the dependency list. You can also filter the catalogue by architecture, scale and tags, and view metadata including training details and licences. ### How is the OpenModelDB API produced? The build script runs generate-thumbnails, then a static Next.js export with NEXT_OUTPUT_EXPORT=true, then generate-api, then fix-db. The API is therefore generated from the same data files the site reads, at build time, rather than served from a separate service. ### What license is OpenModelDB released under? The project is licensed under the GNU General Public License v3.0, with the LICENSE file at the root of the repository. The primary language is TypeScript, and the licence of each individual model is recorded separately in that model's metadata. ## Sources - [Issues](https://github.com/OpenModelDB/open-model-database/issues) - [License: GPL-3.0](https://github.com/OpenModelDB/open-model-database/blob/main/LICENSE) - [OpenModelDB/open-model-database on GitHub](https://github.com/OpenModelDB/open-model-database) - [Project website](https://openmodeldb.info) - [README](https://github.com/OpenModelDB/open-model-database/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openmodeldb-open-model-database