管理日志摄取使用情况

你被收费的项目 #

🌐 What you are charged for

你需要为 Supabase 在计费周期内从你项目的所有服务（Postgres、API 网关、认证、存储、实时、边缘函数等）中收集的日志数据总量付费。

🌐 You are charged for the total volume of log data that Supabase ingests across all your project's services (Postgres, API gateway, Auth, Storage, Realtime, Edge Functions, and others) during the billing cycle.

费用是怎么计算的 #

🌐 How charges are calculated

日志摄取按账单周期内摄取的日志数据字节收费。

🌐 Logs Ingest is charged per byte of log data ingested during the billing cycle.

在你的发票上的用途 #

🌐 Usage on your invoice

在你的发票上，使用情况显示为“日志摄取”。

🌐 Usage is shown as "Logs Ingest" on your invoice.

价格 #

🌐 Pricing

$0.50 每GB，超过你套餐包含的流量后。

计费示例 #

🌐 Billing examples

摄取按字节计费（字节 ÷ 1,000,000,000 × $0.50），不会向上取整到下一个 GB。这些例子用小数 GB 来展示精确度。

🌐 Ingest is billed per byte (bytes ÷ 1,000,000,000 × $0.50), not rounded up to the next GB. These examples use fractional GB to show that precision.

查看使用情况 #

🌐 View usage

你可以在仪表板的组织使用情况页面查看日志摄取使用情况。默认情况下，该页面显示所有项目的使用情况。要查看特定项目的使用情况，可以从下拉菜单中选择它。你也可以选择不同的时间段。

🌐 You can view Logs Ingest usage on the organization's usage page of the Dashboard. The page shows the usage of all projects by default. To view the usage for a specific project, select it from the dropdown. You can also select a different time period.

优化使用 #

🌐 Optimize usage

你 Supabase 项目中的每个服务都会自动生成日志。日志量会随着你的应用流量和行为而变化。

🌐 Every service in your Supabase project generates logs automatically. Log volume scales with your application's traffic and behavior.

降低日志类型的音量，而不是完全关闭它。提高阈值，而不是彻底禁用日志，这样如果以后出问题，你仍然可以获取信息。例如，安全事件或慢查询可能会完全被遗漏。

🌐 Reduce the volume of a log type rather than turning it off completely. Raise a threshold rather than disabling logging outright as this prevents you from having information if something goes wrong later. For example a security incident or a slow query may be completely missed.

你可以通过 自定义 Postgres 配置 来更改下面所有的 Postgres 设置，无论是在 SQL 编辑器还是 Supabase CLI 中。有些更改会立即生效，有些则需要重启数据库。如果你想在重启之前批量更改多个设置，CLI 有一个 --no-restart 选项。完整的可配置日志设置列表以及每个设置的作用，请参阅 Postgres 日志配置 。

🌐 You change all of the Postgres settings below through Custom Postgres Configuration, either from the SQL Editor or the Supabase CLI. Some changes take effect immediately; others require a database restart. The CLI has a --no-restart option if you want to batch several changes together before restarting. See Postgres log configuration for the full list of configurable log settings and what each one does.

从两个最大的杠杆开始 #

🌐 Start with the two biggest levers

先考虑这些选项。它们负责大多数项目的大部分日志量。

🌐 Consider these options first. They are responsible for most log volume on most projects.

• log_statement — 如果你不手动通过原始查询日志来调试应用，例如你的团队依赖 AI 编码助手、APM 工具或查询性能仪表板，可以将其设置为 none。如果你经常在日志浏览器中查看查询文本来调试问题，或者有保留完整语句审计记录的合规要求，就保持 all 开启；如果你只需要记录数据更改，mod 是一个更轻量的选项。
• log_min_duration_statement — 提高阈值（例如，从几毫秒提高到1-2秒），如果你只关心那些慢到能被注意到的查询。只有在你积极进行性能调优阶段时才保持低值，调研结束后再提高回去。
• pgAudit，如果启用——这个扩展本身可能会非常冗长，与 log_statement 无关。如果你不需要超出 log_statement 提供的审计信息，可以关闭宽泛的 pgaudit.log 或 pgaudit.role 配置。

查看这些经常被忽略的设置 #

🌐 Check these often-overlooked settings

• log_connections 和 log_disconnections — 如果你不需要记录每个连接的具体开启和关闭时间，可以关闭它。如果你正在排查连接耗尽或峰值问题，或者有安全需求必须记录所有连接活动，就保持开启。如果这个设置产生了大量日志，你的应用可能没有使用 Supabase 默认提供的连接池（例如 Supavisor）——通过连接池连接可以减少日志量，也降低连接耗尽的风险。
• log_autovacuum_min_duration — 如果你没有积极诊断表维护问题，可以提高阈值或关闭它。如果你之前遇到过自动清理相关的性能问题，保持开启并设置合理的阈值。
• log_temp_files — 如果你没有主动调整查询的内存使用性能，就关闭它。如果你正在调查与排序或连接大量数据相关的慢查询，就保持开启。
• log_lock_waits — 如果你没有看到查询卡住的症状，就关闭它。如果多个进程同时写入同一数据，并且你以前遇到过无法解释的慢速，就保持开启。

如果你的日志莫名其妙地变得很大，就看看这个 #

🌐 Check this if your logs seem unusually large for no clear reason

log_min_messages 控制 Postgres 自身内部日志的详细程度，这与查询活动是分开的。默认值是 warning。如果在排查具体问题时将其调到调试级别，但之后又没有调回去，它可能会产生大量持续的内部信息，而这些信息对日常监控没有用——检查一下当前值，如果你不记得自己调过，就把它重置回来。

自定义 RPC 函数和存储过程也值得查看。一个调用 RAISE NOTICE 或 RAISE LOG 的 PL/pgSQL 函数每次运行都会产生日志输出，无论上述任何设置如何——如果一个经常被调用的函数在每次调用时都记录日志，它可能会占据你流量中很大一部分，否则可能无法解释的份额。

🌐 Custom RPC functions and stored procedures are also worth reviewing. A PL/pgSQL function that calls RAISE NOTICE or RAISE LOG produces log output every time it runs, independent of any of the settings above — if a frequently-called function logs on every invocation, it can account for a large, otherwise-unexplained share of your volume.

通常可以保持默认的设置 #

🌐 Settings you can generally leave alone

log_checkpoints、log_recovery_conflict_waits、log_replication_commands 和 log_startup_progress_interval 天生就是低流量的，或者只有在你使用像复制这样的特定功能时才 Relevant。除非你确定自己在使用相关功能，否则它们很少会对你的总摄取量产生实质性影响。

检查你的新使用基线 #

🌐 Checking your new usage baseline

在你更改设置后，等一两天，然后在仪表板查看你的数据摄取使用趋势，或在日志浏览器检查日志量，以确认更改是否如你预期那样生效。日志量每天可能会因流量不同而波动，所以在下结论前，先观察几天的趋势。如果你不确定当前的使用量是由哪个设置引起的，在更改任何内容之前，先在日志浏览器查看哪种日志条目占用了大部分量。

🌐 After you change a setting, give it a day or two, then check your ingest usage trend in the Dashboard or your log volume in the Logs Explorer, to confirm the change had the effect you expected. Volume can be uneven day-to-day depending on traffic, so look at the trend over several days before drawing conclusions. If you're not sure which setting is responsible for your current usage, check which kind of log entries make up most of your volume in the Logs Explorer before changing anything.

超额 #

🌐 Exceeding Quotas

如果你使用的是付费计划并且已关闭花费上限，或者你的组织使用的是团队计划及以上，你将需要支付任何超出部分的费用。

🌐 If you are on a paid plan and have Spend Cap disabled or your organization is on Team Plan or above, you will pay for any overages.

当你在使用免费计划或启用了消费上限时超出配额，你会收到发送到账单邮箱的通知，并进入宽限期。更多细节请参阅我们的公平使用政策。

🌐 When you are exceeding your quotas while being on a Free Plan or having Spend Cap enabled, you will get a notification to your billing email address and put under a grace period. For more details, refer to our Fair Use Policy.