Visual questions and SQL share one workspace
Metabase sits between company databases and the people who need answers, inside a checkout our lab counted at 21,439 files. A sales manager can choose a table, filter rows, group results, and turn an answer into a chart without learning query syntax. Analysts retain a native SQL editor for work the visual builder cannot express. Saved questions feed dashboards, and subscriptions can send results through email, Slack, or a webhook.
The breadth is useful, though it comes with a large engineering surface. Our checkout at commit ad801f2 contained 21,439 files and about 1,362,621 lines of source. Metabase now covers documents, transformations, canonical metrics, embedded analytics, permissions, and AI-assisted questions alongside its original query and dashboard work. A buyer should map required features to the open-source or paid edition before building around them.
Production needs a separate application database
Metabase v0.63.15 connects to the database or warehouse holding business records. It also keeps user accounts, saved questions, dashboards, permissions, and settings in its own application database. The Docker and JAR quick starts use H2 to make a local trial easy. Official documentation says to avoid H2 in production and recommends PostgreSQL, with MySQL or MariaDB as supported choices.
That extra state changes the operating job. The 384.1 MB checkout is only the source tree; a real deployment also needs a durable application database, warehouse credentials, backups, upgrade rehearsals, and access controls. Removing a Docker container that holds the default H2 files can lose Metabase content. Release v0.63.15 tells operators to back up the application database before upgrading.
Permissions deserve a trial with realistic accounts. Metabase can expose dashboards, downloads, source tables, and embedded views, depending on configuration and edition. Start data-source connections with limited database credentials, then verify what each group can browse and export. A polished question builder does not replace warehouse permissions or a clear owner for metric definitions.
What happened when we ran it
Our measurement setup cloned commit ad801f2 into an unprivileged container with 3 CPUs, 8 GB of RAM, no secrets, and the lab-node:22 image. The repository occupied 384.1 MB. Our scan found 104 CI workflow files, a Dockerfile, and a tests directory. The measured frontend ecosystem was Node with Bun.
Installation failed with exit 1 after 67 seconds. The log starts with bun install v1.4.0. A Node preinstall check then inspected the package-manager context, printed Please use Bun, not npm or yarn., and exited. Bun had launched the command, yet the guard rejected what it saw. The available log does not explain why, so we cannot fairly assign a deeper cause.
Build and tests did not run after that failed install. We therefore have no measured build time, test count, dependency count, or vulnerability result for this commit. The 104 workflow files and tests directory show that the repository contains automation and tests; they do not convert our failed sandbox step into a passing result.
Source work requires more than a Node environment
Metabase v0.63.15 packages the frontend and Clojure backend into one Java JAR, but contributors work across several toolchains. The developer setup installs Node.js, Java, Clojure, Bun, and Babashka, while the build guide also calls for uv and JDK 25. The automated ./bin/dev-install route manages pinned tools, and ./bin/mage doctor checks an existing environment.
This explains why a generic Node 22 image is a poor proxy for a full contributor workstation, even though our failure occurred inside the Bun step. Frontend development uses Bun, while the backend runs through Clojure. End-to-end tests, unit tests, visual tests, database drivers, and the final Uberjar each have their own documented paths. Forking 1,362,621 lines is a continuing maintenance choice.
For product evaluation, the packaged routes are much simpler. The Docker quick start publishes port 3000, and the JAR runs on Java 25. Metabase Cloud adds managed backups, upgrades, SMTP, SSL, and support. Those routes test the actual BI experience sooner than debugging a source environment, unless a planned contribution or fork makes source access the point.
AGPL and commercial editions share one repository
The README for our 21,439-file checkout says the tree includes an open-source edition under the AGPL and commercial editions under the Metabase Commercial Software License. That split calls for an early decision about deployment. An internal analytics server, customer-facing embedding, and a modified redistributed product can raise different licensing and feature questions. Teams should review the files and edition relevant to their use rather than treating every visible feature as part of the free package.
The August 26, 2026 activity supports confidence in maintenance. GitHub recorded a push that day, and Metabase published v0.63.15 on the same date. The repository had 48,947 stars and 4,501 open issues and pull requests combined; GitHub search counted 3,754 open issues. Recent issue and pull-request updates covered search, embedding credentials, LDAP settings, subscriptions, application-database encryption, and frontend modules.
A queue of 4,501 items is too broad to summarize as product quality. Search for the exact database driver, identity provider, embedding mode, and upgrade path you plan to use. Metabase is easiest to recommend for internal analytics where people need quick answers and a data team can manage permissions and definitions. Our 67-second install failure makes the official package the right first trial, while the source tree is for teams prepared to maintain it.