用海外云服务器搭建 Metabase 自建 BI 数据可视化平台完整教程（2026最新版）

Meta Description: 手把手教你用海外云服务器搭建 Metabase 自建 BI（商业智能）数据看板平台：Docker Compose 拉起 Metabase + PostgreSQL 应用库、Nginx 反向代理 + Let's Encrypt 免费 HTTPS、连接 MySQL/PostgreSQL/BigQuery 等 20+ 数据源、自助查询与仪表盘、定时订阅与告警、性能调优与连接池设置、pg_dump 备份与版本升级、安全加固与常见问题，附服务器配置推荐与价格对比。

> 关键词： Metabase搭建、自建BI、数据可视化、开源BI工具、Docker部署Metabase、PostgreSQL应用库、数据看板、Nginx反向代理、Let's Encrypt、海外云服务器

前言

数据这件事有个尴尬的规律：它越多，看得越少。 订单、用户、日志、埋点、财务流水散落在 MySQL、PostgreSQL、Excel 和各个后台里，真到了要回答「这个月转化率比上月高还是低」「哪个渠道的客单价在下滑」这种问题时，往往还得写邮件求开发同学「帮我导一份数据」。

商业智能（BI，Business Intelligence）要解决的就是这个问题——让不懂 SQL 的人也能自己查数据、自己搭看板。但市面上的商业 BI 工具价格劝退：按席位收费、按年订阅，一个小团队一年下来几千美元起。

于是越来越多人把目光投向开源的自建 BI。本文的主角 Metabase 就是这类工具里最流行的一个：GitHub 上 4.96 万 Star，官方宣传「5 分钟上手，非技术人员也能用」，支持 20 多种官方数据源，开源版（Open Source）免费、用户数不限。你要付出的，仅仅是一台服务器和一点点运维成本。

本教程要做的事情很直接：

1. 用一台海外云服务器部署 Metabase——把「查数据、做图表、拼看板」这套能力搬到你自己的机器上； 2. 用 PostgreSQL 作为 Metabase 的应用数据库（存问题、仪表盘、账号、配置），并用 Docker Compose 一条命令拉起整套服务； 3. 用 Nginx 反向代理 + Let's Encrypt 绑定域名、开启免费 HTTPS，让同事在浏览器里直接访问； 4. 接上你的 MySQL / PostgreSQL / 云数据库，做出第一个仪表盘，再把关键指标定时推送到邮箱或 Slack； 5. 最后把性能调优、备份、升级、安全加固这些「生产环境必须有」的环节补齐。

Metabase 提供的是应用数据库（App DB）——它存的是 Metabase 自己的元数据；你的业务数据（订单、用户）仍然留在原来的数据库里，Metabase 只是「连过去查」。搞清楚这个「两层数据库」的概念，后面的部署与备份就不会糊涂。

> 🚀 企业出海需要云架构咨询？ 还没有海外云服务器？通过 5.chengzicloud.cloud 选购阿里云 / AWS / 腾讯云国际版，享专属折扣和中文技术支持。

一、方案选型：自建数据看板为什么选 Metabase

动手之前，先把「数据看板 / 可视化」这一类的几个主流方案分清楚。它们都能「出图」，但回答的问题和前提条件差别很大，选错了会事倍功半。

| 方案 | 技术栈 | 它回答的问题 | 前提条件 | 代价 | |------|--------|-------------|---------|------| | Metabase | JVM（Clojure）+ 应用数据库 | 「业务人员怎么自己查库里的数据、拼经营看板」 | 有业务数据库、想自助分析 | 需自建与维护，复杂建模能力弱于专业 BI | | Grafana | Go + 时序库 | 「服务的指标/日志现在健康吗」 | 有时序数据（Prometheus 等） | 面向运维监控，不擅长业务维度分析 | | Umami | Node + MySQL/PG | 「网站的访问量、来源、转化漏斗」 | 有网站、要埋点 | 只做网站流量分析，不能连业务库自由查询 | | Apache Superset | Python + 元数据库 | 「企业级、多数据源的大规模分析」 | 有专职数据团队 | 部署重、学习曲线陡 | | 商业云 BI | SaaS | 「开箱即用的托管 BI」 | 预算充足、能接受数据上云 | 按席/按年收费，数据不在自己手里 | | Excel / 表格 | 桌面软件 | 「小规模、一次性的手工统计」 | 数据量小 | 数据一多就卡，无法协作与自动刷新 |

一句话总结边界：Grafana 管「服务活得好不好」，Umami 管「网站来的人多不多」，Metabase 管「业务经营得怎么样」。 三者数据模型完全不是一回事，可以并存，不存在谁替代谁。

Metabase 的核心优势在于门槛：它把「查询」拆成两种入口——会 SQL 的人用原生 SQL 编辑器，不会的人用可视化查询构建器（点选字段、拖拽筛选、一键汇总），两边最后产出的是同一种「问题（Question）」，都能放进仪表盘。这正是「5 分钟上手、非技术人员也能用」的底气。

它也有明确的反向边界，选它之前最好心里有数：

- 它不是 ETL / 数仓工具。 它不负责把散乱的数据清洗、聚合、建模到一张宽表——那是 dbt / 数仓的事。Metabase 直接查你的原始库。 - 它不是强管控的企业 BI。 行级/列级权限、SSO、白标这些「企业功能」在开源版里没有，需要 Pro / Enterprise（$575/月起）。开源版适合中小团队与部门级使用。 - 它不替代日志/指标系统。 想看接口耗时 p95、容器 CPU，请去 Grafana（本站有 Prometheus + Grafana 专项教程），别硬塞进 Metabase。

二、服务器配置怎么选：并发人数决定规格

Metabase 是一套 JVM 应用，对内存比较敏感。官方给了一套可以直接套用的资源基线：

- 应用本体（Metabase Server）： 最低 1 核 1 GB 起步；在此之上，每 20 个并发用户增加 1 核 CPU + 2 GB 内存。 - 应用数据库（PostgreSQL）： 单独给 1 核 2 GB 起步；每 40 个并发用户增加 1 核 + 1 GB。

换算成白话：

| 并发用户数 | Metabase 应用建议 | 应用数据库建议 | 合并一台时的规格 | |-----------|------------------|---------------|-----------------| | ≤ 5（个人/试水） | 1 核 1 GB | 与应用同机 SQLite 亦可 | 2 核 2 GB | | ~20（小团队） | 2 核 3 GB | 1 核 2 GB | 2 核 4 GB | | ~40（部门级） | 3 核 5 GB | 1 核 3 GB | 4 核 8 GB | | ~100（全公司） | 6 核 11 GB | 3 核 5 GB | 8 核 16 GB |

> 声明：本文价格数据采集于 2026 年 10 月，仅为公开官网参考区间，实际价格以各家官网实时报价为准，金额单位均为美元（USD）。海外厂商常按小时计费、按秒结算，月费为折算值。

DigitalOcean Droplet（通用型，Linux）

| 内存 | vCPU | SSD | 月流量 | 月费 | |------|------|-----|--------|------| | 512 MiB | 1 | 10 GiB | 500 GiB | $4 | | 1 GiB | 1 | 25 GiB | 1,000 GiB | $6 | | 2 GiB | 1 | 50 GiB | 2,000 GiB | $12 | | 2 GiB | 2 | 60 GiB | 3,000 GiB | $18 | | 4 GiB | 2 | 80 GiB | 4,000 GiB | $24 | | 8 GiB | 4 | 160 GiB | 5,000 GiB | $48 | | 16 GiB | 8 | 320 GiB | 6,000 GiB | $96 |

AWS Lightsail（Linux/Unix 通用型）

| 内存 | vCPU | SSD | 月流量 | 月费 | |------|------|-----|--------|------| | 0.5 GB | 2* | 20 GB | 1 TB | $5 | | 1 GB | 2* | 40 GB | 2 TB | $7 | | 2 GB | 2* | 60 GB | 3 TB | $12 | | 4 GB | 2 | 80 GB | 4 TB | $24 | | 8 GB | 2 | 160 GB | 5 TB | $44 | | 16 GB | 4 | 320 GB | 6 TB | $84 |

（\* Lightsail 低价档的 2 vCPU 为突发型，持续满载时会回落到基准性能。）

阿里云国际版 / 腾讯云国际版：轻量应用服务器与云服务器 CVM / ECS 的入门规格（2 核 2 GB / 2 核 4 GB）大致落在 $8 – $30/月 区间，具体取决于地域（新加坡、硅谷、法兰克福等）、计费方式（包年包月 vs 按量）与带宽/流量包选型，建议在下单页按实时配置核对。

结论与下单建议：

- 个人试水 / 演示：2 核 2 GB（DO $18 或 Lightsail $12）就够，先跑通再扩容。 - 小团队生产（本文推荐）：2 核 4 GB（Lightsail $24 / DO $24）。Metabase 与应用库同机部署，是性价比最高的起点。 - 部门级：4 核 8 GB（DO $48），并把应用库拆到独立实例。 - 磁盘别抠门：应用库要每天备份，加上 Docker 镜像与日志，≥ 80 GB SSD 比较稳妥。

> 🚀 想省一笔开服成本？同样的 2 核 4 GB 规格，通过 5.chengzicloud.cloud 选购阿里云 / AWS / 腾讯云国际版，可享专属折扣与中文技术支持。

三、环境准备：装好 Docker，选对操作系统

Metabase 官方提供 Docker 镜像（metabase/metabase），这是最省心的部署方式——不用手动装 Java、不用管 JAR 包。前提是你的系统有 Docker。

第 1 步，选择操作系统。 强烈建议 Ubuntu 22.04 / 24.04 LTS 或 Debian 12。如果你还在用 CentOS 7，请务必知道：CentOS 7 已于 2024 年 6 月停止维护（EOL），软件源陆续失效，新机器不要再选它。本文命令以 Ubuntu 为准。

第 2 步，安装 Docker Engine。 用 Docker 官方脚本安装（生产环境建议改用官方 apt 源，但脚本方式最快）：

`bash curl -fsSL https://get.docker.com | sh systemctl enable --now docker docker --version docker compose version `

> 注意：这里要装的是 Docker Engine，不是 Docker Desktop——服务器上没有桌面环境，Desktop 也装不了。

第 3 步，确认端口与防火墙。 Metabase 容器默认监听 3000 端口。生产环境不要把 3000 直接暴露到公网，而是让 Nginx 反向代理到它（见第六节）。如果你用的是云厂商的安全组 / 防火墙，只放行 80 与 443 即可。

四、用 Docker Compose 部署 Metabase + PostgreSQL

第 1 步，准备目录。 我们把所有文件放在 /opt/metabase：

`bash mkdir -p /opt/metabase/pg_data cd /opt/metabase `

第 2 步，写 compose.yaml。 这份编排同时拉起两个服务：metabase（应用）和 postgres（应用数据库）。请把 MB_DB_PASS 与 POSTGRES_PASSWORD 换成你自己的强密码 （两处必须一致）：

`yaml services: metabase: image: metabase/metabase:latest container_name: metabase hostname: metabase restart: unless-stopped volumes: - /dev/urandom:/dev/random:ro ports: - 127.0.0.1:3000:3000 environment: MB_DB_TYPE: postgres MB_DB_DBNAME: metabaseappdb MB_DB_PORT: 5432 MB_DB_USER: metabase MB_DB_PASS: ChangeThisStrongPassword MB_DB_HOST: postgres JAVA_TIMEZONE: Asia/Shanghai depends_on: postgres: condition: service_healthy networks: - metanet1 healthcheck: test: curl --fail -I http://localhost:3000/api/health || exit 1 interval: 15s timeout: 5s retries: 5

postgres: image: postgres:16 container_name: metabase-postgres restart: unless-stopped environment: POSTGRES_USER: metabase POSTGRES_DB: metabaseappdb POSTGRES_PASSWORD: ChangeThisStrongPassword volumes: - ./pg_data:/var/lib/postgresql/data networks: - metanet1 healthcheck: test: pg_isready -U metabase -d metabaseappdb interval: 15s timeout: 5s retries: 5

networks: metanet1: driver: bridge `

几个关键点：

- ports 写成 127.0.0.1:3000:3000，意思是只监听本机回环地址，公网访问不到 3000——由 Nginx 在 80/443 上对外服务。这是最省事的「不暴露内网端口」做法。 - volumes 里的 /dev/urandom:/dev/random:ro 是官方示例推荐的映射，避免 JVM 在熵池不足时启动慢、卡在初始化。 - JAVA_TIMEZONE 决定报表默认时区，设成 Asia/Shanghai 更符合中文团队习惯。

第 3 步，拉起服务。

`bash docker compose up -d docker compose ps `

第一次启动会拉镜像、初始化数据库并迁移表结构，大约需要 1–2 分钟。跟踪日志确认它起来了：

`bash docker compose logs -f metabase `

当日志出现 Metabase Initialization COMPLETE 字样就表示初始化完成（按 Ctrl + C 退出日志跟踪，不会停服务）。

第 4 步，验证。

`bash curl -fsS http://127.0.0.1:3000/api/health `

返回 {"status":"ok"} 即代表 Metabase 与应用数据库都健康。此时在浏览器访问 http://<服务器公网IP>:3000 应该能看到 Metabase 的欢迎页（但生产环境请先配好 Nginx 再用域名访问）。

五、为什么必须换掉默认的 H2 应用数据库

Metabase 镜像自带一个嵌入式 H2 数据库。如果你拉起容器时不指定应用数据库，它就默认用 H2，数据以文件形式存在容器里。官方对此有一个非常直白的警告：

> 如果你一直用默认的、基于文件的应用数据库，它最终会不可逆地损坏，你只能从头再来（丢掉所有的问题、仪表盘等等）。

原因有三条，条条致命：

1. 容器是「一次性」的。 每次用新镜像重建容器，容器里的 H2 文件就没了——你的所有工作随之蒸发。 2. H2 不能共享。 它是个本地文件，没法被多个 Metabase 实例同时读，也就无法做负载均衡与高可用。 3. H2 会坏。 它不是为长期生产运行设计的，随使用增长迟早损坏。

所以生产部署的第一原则就是：把应用数据库换成 PostgreSQL（官方第一推荐；MySQL / MariaDB 也可用于生产）。想想看，你辛苦建的几十个问题、仪表盘、账号，全都存在这个库里——它才是整套系统里最不能丢的东西。

第 1 步，先建库。 Metabase 不会替你创建数据库，必须先建好（我们上面的 Compose 已经用 POSTGRES_DB: metabaseappdb 自动建好了，这里补一下手动场景的对照）：

`bash createdb --encoding=UTF8 -e metabaseappdb `

用 MySQL / MariaDB 的话，建库时要指定 utf8mb4：

`sql CREATE DATABASE metabaseappdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; `

第 2 步，用环境变量告诉 Metabase 连哪儿。 就是我们 compose.yaml 里那几行 MB_DB_*，参数含义见下表：

| 环境变量 | 含义 | 示例 | |---------|------|------| | MB_DB_TYPE | 数据库类型 | postgres | | MB_DB_HOST | 数据库地址 | postgres（容器名） | | MB_DB_PORT | 端口 | 5432 | | MB_DB_DBNAME | 库名 | metabaseappdb | | MB_DB_USER | 用户名 | metabase | | MB_DB_PASS | 密码 | 强密码 |

小坑提示：如果你的数据库密码含有 @、#、/ 这类特殊字符，直接拼进 JDBC 连接串（MB_DB_CONNECTION_URI）容易解析出错。这时改用分开传参——只给 MB_DB_CONNECTION_URI 传地址，用户名密码单独用 MB_DB_USER / MB_DB_PASS 传，就不会被特殊字符坑到。

六、Nginx 反向代理 + Let's Encrypt 免费 HTTPS

到这一步，Metabase 只在服务器本机的 3000 端口上运行，还不方便对外访问。我们给它套一层 Nginx 反向代理，再用 Let's Encrypt 免费签一张证书。

第 1 步，安装 Nginx 与 Certbot。

`bash apt update apt install -y nginx certbot python3-certbot-nginx `

第 2 步，解析域名。 把 bi.example.com 的 A 记录指向这台服务器的公网 IP。如果域名托管在 Cloudflare，先关掉代理（切成灰色云的「仅 DNS」），等证书签发成功后再按需打开。

第 3 步，新建反代配置 /etc/nginx/conf.d/metabase.conf：

`nginx server { listen 80; server_name bi.example.com;

location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 300s; client_max_body_size 50m; } } `

三处值得解释：

- proxy_read_timeout 300s：给复杂查询更长的等待时间，避免大查询跑到一半被 Nginx 掐断。 - client_max_body_size 50m：放行 CSV 上传（Metabase 支持上传 CSV 当数据源），默认的 1M 会直接 413。 - Upgrade / Connection 两个头：让 WebSocket 正常工作，保证前端实时刷新。

第 4 步，测试配置并重载。

`bash nginx -t systemctl reload nginx `

第 5 步，一键签发证书并开启跳转。

`bash certbot --nginx -d bi.example.com --redirect -m [email protected] --agree-tos `

Certbot 会自动申请证书、把 HTTP 跳转到 HTTPS，并安装一个自动续期任务（Let's Encrypt 证书 90 天有效，到期前自动换新）。验证一下：

`bash curl -sI https://bi.example.com | head -3 `

返回 HTTP/2 200 就说明域名访问已经通了。此时别忘了把服务器安全组里的 3000 端口关掉——对外只留 80 / 443。

七、首次配置：连数据源、做看板、定时推送

打开 https://bi.example.com，Metabase 会引导你创建管理员账号。完成之后，做三件事。

1）连接你的业务数据库。 进入 Admin settings → Databases → Add a database，选择类型（PostgreSQL / MySQL / MariaDB / SQL Server / BigQuery / Snowflake / ClickHouse / MongoDB 等），填主机、端口、库名、账号密码。Metabase 官方维护了 20 多种数据库驱动，覆盖：

Athena、BigQuery、ClickHouse、Databricks、Druid、MongoDB、MariaDB、MySQL、Oracle、PostgreSQL、Presto、Redshift、Snowflake、SparkSQL、SQL Server、SQLite、Starburst 等。

> 建议用只读账号连接业务库。 给 Metabase 单独建一个只有 SELECT 权限的用户，避免它（或误操作）改动生产数据。

2）做出第一个「问题（Question）」和仪表盘。 在左侧 + New → Question 里选一张表，用过的人会发现它和 Excel 数据透视表很像：点选要看的字段、拖个筛选条件、选个「汇总方式」（求和、计数、平均），图表类型在右侧随时切换。想写 SQL 就切到 Native query 编辑器，写完的结果同样能保存成问题、放进仪表盘。

把几个问题拖到同一个 Dashboard 里，加上筛选器（比如「时间范围」「渠道」），一个可交互的经营看板就成型了。

3）配好发信，启用订阅与告警。 想让看板每周一早上自动发到邮箱 / Slack，或者指标超过阈值就报警，需要先配置 SMTP：Admin settings → Email 里填发信服务器。配好之后：

- Dashboard subscriptions（仪表盘订阅）：按日 / 周 / 月定时把整块看板发出去； - Alerts（告警）：对某个问题设定条件（如「当日订单数 < 100」），满足即通知。

另外建议在 Admin settings → General 里把 Site URL 设成你的正式域名——订阅邮件和告警里的链接才会指向正确地址，而不是 localhost:3000。

八、性能调优：把内存、连接池和后台任务调对

Metabase 跑起来容易，跑得稳要靠几个参数。下面是官方文档里最关键的几条。

1）给 JVM 设好堆内存上限。 JVM 默认会尽可能多吃内存，容易把机器吃穿。官方在压测里就是用下面这个思路限制堆大小的——留出约 20% 给非堆内存：

`yaml environment: JAVA_TOOL_OPTIONS: -Xmx3200m `

一台 4 GB 内存的机器，-Xmx 设到 3200m 左右比较合适（约总内存的 80%）。

2）理解连接池。 Metabase 默认给每个连接的数据库（含应用库）分配一个池，每池上限 15 个连接。如果并发的人变多、看板卡住，可以调大应用库的池上限：

`yaml MB_APPLICATION_DB_MAX_CONNECTION_POOL_SIZE: 30 `

注意：调大连接池后要同步给应用数据库多配些内存，否则数据库会在内存不足时排队，用户反而觉得更卡。

3）给后台异步任务留够 CPU。 Metabase 会周期性地跑一批后台任务：sync（同步表结构）、scan（扫描值）、fingerprinting（字段指纹）、field values（筛选值）、model caching（缓存模型）、question metadata（问题元数据）。这些任务每个会占用一个 CPU 核，而且会留一个核专门用于响应用户请求（一个核大致能支撑 10 个并发用户）。

所以：4 核的机器，最多同时跑 3 个后台任务。 如果你发现某个时段 CPU 飙高，先去日志里确认是不是这些任务在跑，再把它们排到业务低峰期执行。

4）按阈值设监控。 官方建议盯住这几个数，一旦越线就告警：

| 对象 | 指标 | 警戒线 | |------|------|--------| | Metabase 应用 | API 响应时间 | 明显变慢即查 | | Metabase 应用 | CPU 使用率 | 80% – 90% | | Metabase 应用 | 内存使用率 | 80% | | 应用数据库 | CPU 使用率 | 90% | | 应用数据库 | 内存使用率 | 80% | | 应用数据库 | 磁盘使用率 | 80% | | 应用数据库 | 磁盘 IOPS | 不超过磁盘标称值 |

Metabase 还内置了 Prometheus 指标端点，可以直接接进现有的 Prometheus + Grafana 监控栈（本站有专项教程）。

5）健康检查端点。 编排系统可以用它们判断实例状态：

- GET /api/health（等价于 GET /readyz）：同时检查 Metabase 与应用数据库连接； - GET /livez：只检查 Metabase 能否响应请求（存活探针）。

> ⚠️ 别用「不用就自动关机」的弹性实例跑 Metabase。 原因有二：一是后台任务必须持续跑，关机就断；二是每次冷启动，第一批登录的用户会遭遇严重的性能惩罚。这也正是本文建议用固定规格的云服务器而非 Serverless 容器来部署的原因。

九、备份与升级：数据只有一个库，别赌运气

备份其实非常简单——因为 Metabase 的全部运行时数据（问题、仪表盘、账号、配置）都放在那一个应用数据库里。 换成 PostgreSQL 后，一次 pg_dump 就是全量备份：

`bash docker exec metabase-postgres pg_dump -U metabase metabaseappdb \ | gzip > /root/backup/metabaseappdb-$(date +%F).sql.gz `

建议用 cron 每天凌晨跑一次，并定期把备份同步到异地。官方对应用数据库的维护建议也很明确：

- 每天备份一次； - 每周对数据库做一次 VACUUM / ANALYZE； - 不再使用的问题与仪表盘，定期归档、清理。

> H2 老数据怎么备份？如果还在用 H2（不推荐），就是停掉 Metabase 后拷走 metabase.db.mv.db 文件。但既然你已经按第五节换成了 PostgreSQL，就忘掉 H2 吧。

升级版本。 Metabase 发版很勤，升级方式就两步——拉新镜像、重建容器：

`bash cd /opt/metabase docker compose pull metabase docker compose up -d `

升级前务必先备份，并去官网 Release Notes 里搜索 Backward-incompatible changes（破坏性变更）。版本号语义要记牢：

- 小版本更新（如 v0.63.18 → v0.63.19）：通常不改应用库表结构，可以平滑升级甚至回退； - 大版本更新（如 v0.63 → v0.64）：会改表结构，升级期间可能停机，时长取决于应用库大小，请安排在维护窗口。

关于镜像标签： 生产环境建议固定版本号而不是用 latest，避免某次重启被动升到新大版本。本文成稿时 Docker Hub 上的标签包括滚动线 v0.64.x（最新 v0.64.1）、稳定线 v0.63.x（v0.63.19）以及长期支持线 v0.58-lts。稳妥做法是锁定一个具体版本：

`yaml image: metabase/metabase:v0.63.19 `

需要回退到旧版时，把标签改成目标版本、再 docker compose up -d 即可（记得先确认应用库表结构兼容）。

十、安全加固清单

最后过一遍上生产的加固清单：

1. 不暴露 3000。 容器端口只绑 127.0.0.1，对外只开 80 / 443，云安全组同步收敛。 2. 用只读账号连业务库。 Metabase 连接数据源时，一律用只有 SELECT 权限的账号。 3. 强口令 + 最小权限。 管理员账号、应用库密码都用强口令；应用库只允许 Metabase 所在容器访问。 4. 敏感参数走 Docker Secrets。 数据库密码、SMTP 密码等支持以 _FILE 后缀从文件读取（如 MB_DB_PASS_FILE、MB_EMAIL_SMTP_PASSWORD_FILE），避免明文写在编排文件里。 5. HTTPS 强制。 用第六节的 Certbot --redirect，让所有 HTTP 请求 301 跳到 HTTPS。 6. 及时升级。 Metabase 迭代快，安全修复随版本发布，别长期停留在旧版本。 7. 限制数据权限。 开源版提供基于分组（Groups）的集合权限与数据访问控制；行级 / 列级权限、SSO 是 Pro 及以上版本的功能——有合规要求时按需评估。 8. 日志与审计。 保留 Metabase 与 Nginx 日志，便于排查与审计（Pro 版另有更细的审计能力）。

十一、常见问题 FAQ

Q1：Metabase 免费吗？开源版和 Pro / Enterprise 差在哪？ 开源版（Open Source）完全免费、用户数不限，20+ 数据源的官方驱动、无限的问题与仪表盘、AI 提问与 SQL 生成都包含在内。付费版主要是企业级管控能力：Starter（$100/月起，首 5 用户包含，超出 $6/用户/月）、Pro（$575/月起，首 10 用户包含，超出 $12/用户/月）提供行级 / 列级权限、SSO、缓存控制、使用审计、白标、多租户嵌入等。中小团队用开源版完全够。

Q2：跑 Metabase 需要多大的服务器？ 最低 1 核 1 GB 起步，但生产建议 2 核 4 GB。往上按「每 20 并发 + 1 核 + 2 GB」线性加：约 40 并发用 4 核 8 GB，约 100 并发官方建议 6 核 11 GB。

Q3：应用数据库一定要用 PostgreSQL 吗？ 官方第一推荐 PostgreSQL，MySQL 8.4+ / MariaDB 10.6+ 也可用于生产（注意字符集必须是 utf8mb4）。唯一不能用的是 H2（见 Q4）。

Q4：用默认的 H2 会怎样？ 不要用。官方原话是：一直用 H2，它最终会不可逆地损坏，你只能从头再来。容器一重建数据就丢，也没法做高可用。生产必须换 PostgreSQL。

Q5：应用数据库和我业务数据库是一回事吗？ 不是。应用库（App DB）存的是 Metabase 自己的问题、仪表盘、账号、配置；业务库是你的订单、用户数据。Metabase 连过去只读查询业务库，并不把数据搬走。所以备份重点是应用库。

Q6：数据源连不上，怎么排查？ 先确认三件事：① 容器里能不能解析并访问到数据库地址（MB_DB_HOST 用的是容器名还是主机 IP，别搞混）；② 账号密码、端口、库名是否正确；③ 数据库是否允许来自服务器 IP 的连接（云数据库要加白名单）。密码含特殊字符时，改用 MB_DB_USER / MB_DB_PASS 分传，别硬拼连接串。

Q7：看板打开很慢怎么办？ 先看是不是后台任务（sync / scan / fingerprinting 等）在抢 CPU——把它们排到低峰期；再检查 JVM 堆内存（-Xmx）是否太小、应用库是否在同机磁盘上；数据量特别大时，优先用原生 SQL 写好查询或建物化视图 / 预聚合表，而不是让可视化构建器每次实时扫全表。

Q8：怎么让 Metabase 只在内网访问？ 把容器的 ports 写成 127.0.0.1:3000:3000（本文默认就是），并且不配置 Nginx 对外反代，改由 VPN / 内网 IP 访问即可。

Q9：我已经用 H2 跑了一阵，能迁到 PostgreSQL 吗？ 可以，官方提供从 H2 迁移到 PostgreSQL 的专门文档（迁移支持是有限度的，务必先备份 H2 文件）。迁移越早越好——问题和仪表盘越多，迁移越麻烦。

Q10：升级会丢数据吗？ 正常的 docker compose pull && docker compose up -d 不会动数据——数据在应用库里。但大版本升级可能改表结构并需要停机，所以升级前先 pg_dump 备份，并查阅 Release Notes 的破坏性变更。

Q11：Metabase 和 Grafana 到底怎么选？ 看数据形态与使用者：Grafana 面向运维的时序指标与日志（Prometheus、Loki），图表偏「系统健康度」；Metabase 面向业务的关系型数据自助分析，图表偏「经营指标」，且强调非技术用户也能上手。两者是互补关系，很多团队两个都装。

Q12：支持中文吗？ 支持。Metabase 界面提供简体中文等多语言，图表中的中文正常显示（应用库用 UTF-8 即可）。报表订阅、告警邮件也支持中文内容。

Q13：如何做定时邮件 / Slack 报表？ 先在 Admin settings → Email 配好 SMTP，然后在仪表盘右上角设置 Subscriptions，选频率（每日 / 每周 / 每月）与收件人即可。指标类告警则在问题页设 Alerts，达到阈值自动通知。

Q14：整套自建下来一个月大概多少钱？ 只跑 Metabase + PostgreSQL，2 核 4 GB 的海外云服务器约 $24/月（Lightsail $24 / DigitalOcean $24）。对比按年订阅的商业 BI（一个小团队动辄几千美元/年），自建通常几个月就回本，而且数据和配置始终在你自己手里。

结语

到这里，你就拥有了一套完全属于自己的数据分析平台：Metabase 负责让业务同事自己查数、自己搭看板，PostgreSQL 稳稳存住所有工作成果，Nginx + Let's Encrypt 守住门面，Docker Compose 让升级与迁移只差一条命令。它不按人头收费，不会在某次续费时给你涨价，也不会哪天突然宣布关停。

维护它的日常其实很轻：每天备份应用库、每周 VACUUM、需要新功能时 docker compose pull。剩下的时间，就交给那些终于能被一眼看懂的数据吧。

如果你还想在这套栈上继续扩展，下面这些站内教程都能无缝衔接。

延伸阅读：

- 用海外云服务器搭建 Docker + Portainer 容器管理平台教程 - 海外云服务器 MySQL / PostgreSQL 数据库服务搭建教程 - Nginx 反向代理 + Let's Encrypt SSL 证书配置完整教程 - 海外云服务器监控告警搭建（Prometheus + Grafana）教程 - 用海外云服务器搭建 Umami 网站访问统计分析教程 - 海外云服务器备份与灾难恢复实战教程

> 本文由 5.chengzicloud.cloud 提供，点击访问首页了解更多海外云服务器部署方案和专属优惠。