Supabase compute and disk sizing

A Supabase project stops being affordable or available for one of four reasons: compute throttle, disk throttle, quota, or read-only. This reference covers every compute size and both disk types, and marks per claim whether the behaviour comes from the docs or from a live test here; several of them disagree.

The measured numbers come from a battery written against throwaway projects on the Management API (Free, Pro, and Team orgs; 2026-08-19, paid-plan fill and grow steps added 2026-10-01 in ap-southeast-1), each project deleted in the same run. The compute-disk RUNLOG does not record the AWS region (the platform-downtime run cross-referenced below was in ap-southeast-1; the compute-disk RUNLOG does not record its own region). Claims that were not run are still cited to the docs and labelled as such.

TL;DR

• Compute never upgrades itself; disk never shrinks. Compute resize is a 1-2 minute window (measured); disk decrease is rejected outright.
• Disk autoscale fires at ~90% usage (measured on Pro). A new Pro project starts on 2 GB and the first grow went to 8 GB, the next +50% to 12 GB. Its settings read back as nulls and cannot be written through the Management API (measured) - the dashboard is the only surface.
• Paid-plan read-only at 95% disk holds (measured) and lifted by itself once autoscale grew the disk. A fast import after autoscale had already grown the disk once skipped read-only in one run of two and filled the disk: 53100 No space left on device and a seven-minute outage while the project status read healthy.
• The Free-plan read-only wall is not the documented 500 MB: measured reads accepted to ~726 MB database size, then ERROR: 25006: cannot execute INSERT in a read-only transaction. Recover with DELETE (TRUNCATE is also blocked), not vacuum alone.
• The disk modification quota answered 429 with text “once per four hours” (measured) - the docs describe four modifications per rolling 24 hours. Enforcement was nondeterministic across runs.
• The “Large compute or above” gate on disk IOPS/throughput is UI-only: the API accepted AND applied elevated IOPS on a Micro project (measured, confirmed by follow-up read).

Pick the pressure first

1. CPU at a sustained cap: upgrade compute (Compute sizes).
2. Disk IO % consumed above 0: raise IOPS or move to io2 (Disk).
3. The database outgrows the disk: grow the disk, manually first (Manual expansion + modification quota).
4. The bill is over quota: the spend cap option (Spend cap).

Compute sizes

Prices and recommended database size from the docs.¹

Size	Hourly	Monthly	CPU	Memory	Max database (recommended)
Nano	$0	$0	shared	up to 0.5 GB	500 MB
Micro	$0.01344	~$10	2-core shared	1 GB	10 GB
Small	$0.0206	~$15	2-core shared	2 GB	50 GB
Medium	$0.0822	~$60	2-core shared	4 GB	100 GB
Large	$0.1517	~$110	2-core dedicated	8 GB	200 GB
XL	$0.2877	~$210	4-core dedicated	16 GB	500 GB
2XL	$0.562	~$410	8-core dedicated	32 GB	1 TB
4XL	$1.32	~$960	16-core dedicated	64 GB	2 TB
8XL	$2.562	~$1,870	32-core dedicated	128 GB	4 TB
12XL	$3.836	~$2,800	48-core dedicated	192 GB	6 TB
16XL	$5.12	~$3,730	64-core dedicated	256 GB	10 TB
>16XL	-	-	custom	custom	custom

Micro through 2XL is shared and burstable; Large and above are dedicated.¹ Burstable means spikes are fine until burst credits drain; then baseline governs.

Nano cannot start on a normal paid (Pro) org: the try was rejected with 400 Minimum instance size on paid plans is Micro (measured, create + PATCH + catalogue; instance-sizing I01, 2026-08-17). On a Free org, Nano pauses and restores fine; wake measured ~162-204 s (I04; in the lab’s AGENTS.md, no RUNLOG entry). Two lifecycle rules follow from the same experiment:

• Do not wake a legacy free-era paused project on a paid org unless you accept that it joins the always-on Micro floor for good. The restore was accepted, ACTIVE_HEALTHY arrived about 30 minutes later, and POST /v1/projects/{ref}/pause then answered 400 {"message":"Project is not free-tier. Please downgrade it to free-tier first and try again."}; pause eligibility follows the org’s current plan rather than the project’s lineage (I03, 2026-08-18).
• On a platform-plan org the create default is Nano (224 MB shared_buffers) and that project can pause; do not pass desired_instance_size there. Nano is absent from every addon catalogue because it is not a purchasable or resize target on any plan (instance-sizing addendum 2026-08-24/25, from sfp-platforms S01).

Per-size IO ceiling (docs, unmeasured here)

Baseline = sustained. Max = burst until credits drain.¹

Size	Baseline MB/s	Max MB/s	Baseline IOPS	Max IOPS
Nano	5	261	250	11,800
Micro	11	261	500	11,800
Small	22	261	1,000	11,800
Medium	43	261	2,000	11,800
Large	79	594	3,600	20,000
XL	149	594	6,000	20,000
2XL	297	594	12,000	20,000
4XL	594	594	20,000	20,000
8XL	1,188	1,188	40,000	40,000
12XL	1,781	1,781	50,000	50,000
16XL	2,375	2,375	80,000	80,000

The docs go further up to 24XL/48XL at 3,750 / 5,000 MB/s baseline.¹

Per-size pg limits (docs; Micro and Small measured here)

Size	rep slots	wal senders	max connections	pooler clients
Nano	5	5	60	200
Micro	5	5	60	200
Small	5	5	90	400
Medium	5	5	120	600
Large	8	8	160	800
XL	24	24	240	1,000
2XL	80	80	380	1,500
4XL	80	80	480	3,000
8XL	80	80	490	6,000
12XL	80	80	500	9,000
16XL	80	80	500	12,000

Measured (D01): Micro max_connections 60, max_wal_senders 10, max_replication_slots 10, shared_buffers 256 MB; Small 90 / 10 / 10 / 512 MB - the wal senders and rep slots above are the docs’ plan-wide ceilings; pg’s own floor per size sits lower.¹ Downgrading below your replication-slot usage is rejected because the server will not start.¹

Resize: duration + downtime (measured)

The order Micro -> Small -> Large -> Small -> Micro was run with REST (anon table read) and Auth health sampled every 250 ms:

op	settle	REST max contiguous outage	Auth max outage
upgrade Micro->Small	105 s	1.0 s	0 s
upgrade Small->Large	61 s	17.0 s	0 s
downgrade Large->Small	61 s	0 s	0 s
downgrade Small->Micro	73 s	0 s	0 s

Adjacent resize PATCHes are rate-limited independent of rebuild: the second within a window answered 429 We are still processing addon changes, please try again in N minute(s). A separate experiment (platform-downtime D03, 2026-08-04, n=1, 500 ms sampling from a Singapore IPv4 vantage) measured a Micro -> Small resize at 131 s on GET /auth/v1/health (anon key, HTTP 521) and 207 s on the pooler, with REST at zero failed samples.² That run and D09 disagree on the same endpoint: D09’s /auth/v1/health probe saw 0 s of contiguous outage across four resizes. The two runs used different rigs, projects and vantages; a side-by-side run has not been done. Docs cite “typically less than 2 minutes”.¹ The measured restart and resize dwell times per connection path are in the platform operation-cost reference.

Compute billing

Compute is billed hourly (paused projects don’t accrue) and is not spend-cap eligible; the cap only bounds eligible usage items.³

Disk

Types (defaults doc-verified)

	gp3	io2
Price/GB-month	$0.125	$0.195
IOPS price	$0.024/IOPS-month	$0.119/IOPS-month
Throughput	125 MB/s incl, then $0.95/MB/s (max 1,000)	scales with IOPS
Max IOPS	16,000 (from 32 GB size)	80,000 (from 80 GB size)
Max size	16 TB	60 TB
Effective ceiling	min(compute size, provisioned disk)

Provision more than baseline per GB: gp3 +500 IOPS/GB and +0.25 MB/s/IOPS; io2 +1,000 IOPS/GB.¹ The “Large compute” gate on these is UI-only (measured, below).

Database size vs disk size

Database size = pg_database_size() (tables + indexes + materialised views). Disk = that + WAL + system files + an empty baseline of ~40-60 MB.⁴ The Free plan quota is on the first; paid-plan read-only trips on the second at 95%.⁴ WAL is not a rounding error on a small volume: Micro runs min_wal_size 1GB and max_wal_size 4GB, and under bulk inserts pg_wal held 816-992 MB of a 2 GB disk, so read-only tripped with an 803 MB database (D10, measured).

• Delete data: database size does not drop until vacuum runs (dead tuples); TRUNCATE drops instantly. Both measured.
• Disk util endpoint (GET /config/disk/util) answered 200 on Free and Pro (measured) - usable in org-wide cost probes. It is a five-minute sample: the same timestamp and value came back for up to five minutes, and once it returned the pre-fill baseline while the disk was full (D10).

Autoscale: defaults and the missing surface

Docs describe: trigger 90% usage, grow by growth percent (default 50%), min increment 1 GB, bounded by max size default 8 GB with the spend cap on.⁴

The settings are readable as nulls and not settable through the Management API (measured). On both Pro and Team orgs the autoscale GET answered 200 with every field null and PUT/POST/PATCH all answered 404. A re-probe on a platform-plan org in September 2026 got the same 404 on PATCH, PUT, POST and DELETE, carrying the identical Cannot VERB /v1/projects/<ref>/config/disk/autoscale body that an entirely unknown path returns, and the GET read {"growth_percent":null,"min_increment_gb":null,"max_size_gb":null}. The dashboard’s editable growth/min/max fields are the only mutation surface. The Data API toggle is different: the http-tier-lockdown experiment found it maps to the Management API’s db_schema field, measured in the AWS PrivateLink reference. Tracking the autoscale values is a manual IaC exercise.

POST /config/disk accepts autoscale keys and discards them. Sent with a full valid attributes object plus growth_percent and max_size_gb - inside attributes, at the top level, and as a nested autoscale object - every shape answered 201, and the autoscale GET still read all-null after a 60 second settle, so a caller gets a success code and no cap. Reaching that point needs the complete attribute set; a partial body is rejected on the missing field (attributes.type, then attributes.iops) rather than on the autoscale keys, so a probe that stops at the first 400 concludes “rejected” when the real answer is “accepted and discarded”.

On the Free tier: measured baseline disk was 2 GB (docs claim 1 GB) and the disk did not grow at 90%+ through a fill, so autoscale did not prevent read-only.⁴

On Pro it fires (D10, 2026-10-01). A fresh project also starts on 2 GB. With the fill paced at ~25 MB per util sample, the sample crossed 90% (91.1%) and the volume grew 2 GB -> 8 GB within about two minutes, with no write refused. A later grow on the same project went 8 GB -> 12 GB. The first step lands on the 8 GB plan baseline rather than adding 50%, although the notification email says “Each expansion increases the disk by 50%” directly above “Disk Size: 2GB -> 8GB”. The second grow came ten minutes after the first, while a manual POST /config/disk on the same project was answering the four-hour 429, so that cooldown binds manual changes and not autoscale.

Manual expansion + modification quota

Increase is OK (HTTP 201, +200 GB cap per change); decrease is refused (HTTP 400, measured).⁴

From the 2 GB starting volume the smallest grow is 6 GB (D11, measured). 4 and 5 GB are refused on the gp3 IOPS floor: 400 Invalid IOPS value for gp3 volume 3000. Minimum is 3000. Max is 500 IOPS per GB or 80,000, whichever is lower. 6 GB answered 201 with an empty body and read back within 10 seconds. The 80,000 in that message is not the 16,000 gp3 maximum in the table above, which comes from the docs.

Modification quota measured: 429 Database disk can only be modified once per four hours. Last modified at <UTC>, where the docs say “four modifications within a rolling 24-hour window”.⁴ One run also accepted 5 consecutive increases in one burst, so enforcement was nondeterministic across runs; plan for a cooldown that can fire on the second change, and raise the disk before a bulk import that would take the volume past 90%. HTTP 429 is also the Management API’s general rate-limit signal - a separate mechanism from this quota; its budget and back-off are worked through in the Management API guide.

Read-only mode

Free plan (measured): accepts to ~726 MB database size, then a write fails with ERROR: 25006: cannot execute INSERT in a read-only transaction; a SELECT on the management endpoint answered 201 the whole time. The documented 500 MB was not the boundary in this run,⁴ and recovery required DELETE (TRUNCATE was rejected) or the override GUC set default_transaction_read_only = 'off' once below the threshold.⁴

Paid plans (Pro, D10, measured): read-only at ~95% disk util as documented,⁴ with the same 25006 error, GET /readonly reading {"enabled":true}, and about three minutes of 57P03 the database system is not accepting connections before it. Autoscale grew the disk about four minutes after the trip, and read-write came back by itself once the grow landed, without a Postgres restart.

The documented “>1.5x the current size” import rule⁴ did not fire as written: 385 MB loaded onto a 203 MB database (1.90x) in 26 seconds was accepted with read-only off. The trigger is disk utilisation; the ratio matters only when it pushes utilisation over the line.

Read-only is not guaranteed to come first. With autoscale’s grow already spent (a manual POST answering the four-hour 429), a burst of 100 MB every 6 seconds crossed the 90-95% band between two five-minute util samples. In one run it failed on ERROR: 53100: could not extend file ...: No space left on device; every query then answered 57P03 for seven minutes and Postgres restarted, while GET /projects/{ref} read ACTIVE_HEALTHY throughout. The reproduction run at the same rate got read-only at 95.1% instead and was writable again 492 seconds later, also after a restart. In both, autoscale grew the disk 8 GB -> 12 GB and the project came back read-write with nothing done by the caller.

Disk IOPS/throughput gate (dashboard-only)

The dashboard says “Adjusting your disk configuration requires LARGE Compute size or above.” Through the API the raise was accepted and stuck on Micro (measured, verified by follow-up GET), so a PAT bypasses the gate without a warning, and IOPS billing starts regardless.

Spend cap (and where compute/disk escape it)

Spend cap ON = eligible overages blocked past quota after notification + grace period, ending in Fair Use restriction; it is enforced on the billing path and does not break requests (measured).³

Exclusions (never capped): compute hours, disk throughput, disk IOPS-hours, custom domains, PITR, read replicas, IPv4, branching, advanced MFA/SSO, log drains.³ Team plan has no spend cap at all - overages are simply billed.³

Ops playbook

Each practice names the module it rests on; module ids resolve in the compute-disk RUNLOG and the instance-sizing RUNLOG. A line marked “docs” or “design choice” is not a measurement.

• Expand the disk before a bulk import: size the import against free disk (data + WAL + system), not against database size. If it would take the volume past 90%, expand manually first (single POST). A fast import outruns the five-minute util sample and autoscale, and after autoscale has grown the disk once it ended in a full disk and an outage in one run of two. Then re-check the quota before a second attempt (D03 quota; D10 fill).
• Schedule the next disk change from the 429 body: once the quota fires, its message carries Last modified at <UTC>, so parse the timestamp and schedule from it rather than re-trying blind (D03).
• Space resize PATCHes: wait >= 2 minutes between adjacent resize PATCHes, or the second returns 429 with still processing (D09).
• Poll for ACTIVE_HEALTHY after a resize with GET /v1/projects/{ref} instead of sleeping a fixed time: settle ran 61-105 s across four operations (D09) and 107 s on D01.
• Size client retries for the resize gap: REST dropped during both upgrades, 1.0 s of contiguous failure on Micro -> Small and 17.0 s on Small -> Large; both measured downgrades were 0 s. The default supabase-js client took 4 attempts and ~7.0s to ride out three 503s (edge-resilience W02); whether it survives a 17.0 s gap was not measured (D09; W02).
• Rehearse the resize mechanics on a downgrade if you need a cheap dry run - PATCH, settle, 429 spacing - not the outage: both measured downgrades produced 0 s of REST outage (Large -> Small, Small -> Micro) while both upgrades did not (D09).
• Read the addon GET for null when returning to Micro, not for ci_micro: Micro is the absence of a compute addon (platform-downtime D04).
• Do not wake a legacy free-era paused project on a paid org unless you accept it can never be re-paused: 400 Project is not free-tier after a ~30 minute wake (instance-sizing I03).
• Do not pass desired_instance_size on a platform-plan org: the create default there is Nano, which can pause; Nano is in no addon catalogue on any plan (instance-sizing addendum 2026-08-24/25).
• Alert on database size, not disk utilisation, on Free projects below ~700 MB: read-only hit at ~726 MB of database size on a 2 GB disk and autoscale did not fire during the fill (D05, D06); /config/disk/util answers on Free (D05) if you also want the disk figure.
• Verify a fresh project’s disk with GET /config/disk before relying on the documented baseline: Free started at 2 GB, not 1 GB (D05), and Pro started at 2 GB, not 8 GB (D10). The first manual grow from there is 6 GB (D11).
• Watch database health, not project status, during a disk event: the project read ACTIVE_HEALTHY through a seven-minute full-disk outage (D10). Probe with a query.
• Count WAL when alerting on a small volume: pg_wal held about half of a 2 GB disk under bulk load (D10).
• Raise IOPS on a Micro via the API only if you accept the bill: the POST was accepted and applied on Micro, and IOPS billing starts regardless of the dashboard’s Large-only text (D08). Whether IO throughput improved was not measured; D08 verified the config stuck.
• Size on CPU and IO burn: CPU utilisation + Disk IO % consumed (the burst-budget drain metric: >0 means past baseline). Over it -> upgrade.¹ (docs)
• Pin autoscale settings outside the API: the API reads them as nulls and cannot set them, and the disk write returns 201 while ignoring the keys - so do not treat a 2xx there as a cap being applied. Pin their intended state in IaC and audit the dashboard manually (D04, D07). If you bill on provisioned capacity, poll /config/disk/util and raise capacity deliberately with POST /config/disk once approved; that schedules the charge but does not stop autoscale firing between polls.

Not measured: recovery from paid-plan read-only by freeing space under the override GUC (every refusal in D10 was cleared by autoscale first); autoscale on Team or the platform plan; resize windows above Large or from a non-local vantage; whether the D09 REST gaps are per-client or per-vantage; the disk quota’s determinism (D03 varied run to run).

Where the docs disagree with runtime

Doc claim	Runtime measured	Severity
read-only at 500 MB database (Free)	read-only at ~726 MB, reads survive	docs stale
4 modifications / 24 h	429 once/4h, nondeterministic	docs text differs, quota exists
Free disk starts 1 GB	started 2 GB	docs understate
autoscale “increases the disk by 50%” (docs and email)	first grow 2 -> 8 GB, then 8 -> 12 GB	first step differs
read-only at 95% protects the disk	true when the fill is slow; a fast burst after a spent grow hit 53100 disk full and a 7 min outage in one run of two	gap in the guarantee
import >1.5x current size trips read-only	1.90x accepted, read-only off	rule does not hold as written
gp3 max IOPS 16,000	API message: 500 per GB or 80,000	docs and API disagree
Large-only for IOPS/throughput	accepted + applied on Micro	UI-only gate
autoscale config via API	verbs 404; GET empty or all-null; POST /config/disk takes the keys, returns 201, applies nothing	surface gap, and it fails silently

Each measured row above comes from the supabase-lab pvlab harness, module ids D01-D09 (2026-08-19) and D10-D11 (2026-10-01) under experiments/compute-disk, 2026-08-19, and re-runs are driven from the experiment’s probe scripts - the full run log is RUNLOG.md; the consolidated reference is COMPUTE-DISK.md at the repo root.

Reading the numbers

• Settle seconds are measured from PATCH -> ACTIVE_HEALTHY status flip. Treat them as a floor; longer providers and disks stretch it.
• contiguous-outage values in the resize table are the MAX visible gap across sampled clients - percent-ok inside a window can dip below that without creating an officially long gap.
• Disk quota behaviour varied run to run (bursts accepted, then reject); treat the limit as volatile rather than a fixed number to schedule against.

Evidence, by module

Measured claims map to module ids D01-D09 in the experiment, plus the borrowed modules listed under Modules - platform-downtime D03/D04, instance-sizing I01/I03/I04, sfp-platforms S01 and edge-resilience W02; the documented and not-run rows rest on the cited pages only.

Claim	Status	How it was checked
Per-size pg floors: Micro max_connections 60, wal senders 10, rep slots 10; Small 90 / 10 / 10	measured	D01 - pg_settings read on a Pro org, resize to Small, re-read
Disk decrease refused (HTTP 400); increase accepted (HTTP 201)	measured	D02 - attribute mutations on a fresh Pro project
Modification quota: 429 “once per four hours”; a 5-mod burst accepted in one run	measured	D03 - serial +1 GB increases until one rejected
Autoscale on a Pro org: GET all-null, PUT/POST/PATCH 404	measured	D04 - verb probes against the autoscale endpoint
Free-org baseline disk 2 GB (docs: 1 GB); no growth at 90%+ through a fill	measured	D05 - continuous fill on a Free project
Free read-only at ~726 MB database size (docs: 500 MB); reads kept answering; TRUNCATE rejected, DELETE required for recovery	measured	D06 - write rejection, endpoint SELECT, and recovery in the same fill run
Autoscale gap identical on a Team org	measured	D07 - the same verb probes as D04
IOPS/throughput raise accepted and applied on Micro; the Large gate is UI-only	measured	D08 - config/disk POST, verified by follow-up GET
Resize settle 105/61/61/73 s; max contiguous outages 1.0/17.0/0/0 s; Auth 0 s	measured	D09 - REST and Auth sampled every 250 ms across the sequence
Nano rejected on a paid org; Free-org wake ~162-204 s	measured	instance-sizing I01 (create + PATCH + catalogue); I04 (figure in the lab’s AGENTS.md, no RUNLOG entry)
Legacy free-era paused project on a Pro org: wake ~30 min, then 400 Project is not free-tier on pause	measured	instance-sizing I03, 2026-08-18
platform-plan org creates Nano by default (224 MB shared_buffers), and it can pause	measured elsewhere	sfp-platforms S01 via the instance-sizing addendum, 2026-08-24/25
Per-size price, IO ceiling, and pg ceiling tables, incl. 24XL/48XL at 3,750 / 5,000 MB/s baseline	documented	not run; cited to the Compute and Disk page
Disk autoscale defaults: 1 GB minimum, 8 GB maximum with spend cap	documented	not run; cited to the Database Size page
Pro starts on 2 GB; autoscale fires at ~90% util: 2 -> 8 GB, then 8 -> 12 GB; not bound by the manual 4 h cooldown	measured	D10 - paced fill with a fresh util sample per batch, then a burst
Paid-plan read-only at ~95% (25006), lifted automatically after the grow	measured	D10 run 1 - unpaced fill on a 2 GB Pro project, recorded in the RUNLOG
1.90x import onto a 203 MB db: no read-only	measured	D10a - seed then back-to-back burst
Burst after a spent grow: 53100 disk full and a 7 min 57P03 outage with status healthy (1 of 2 runs); read-only at 95.1%, writable after 492 s (the other)	measured	D10c/D10d - burst with the manual POST answering 429, then hands-off recovery poll
Grow from 2 GB: 4/5 GB 400 on the gp3 IOPS floor, 6 GB 201	measured	D11 - curl replay, recorded in the RUNLOG

Modules

Module	Experiment	Test	Artifact
D01	compute-disk	d01-compute-pg-limits.ts	none published
D02	compute-disk	d02-disk-mutations.ts	none published
D03	compute-disk	d02-disk-mutations.ts	none published
D03	platform-downtime	d03-resize-up.ts	none published
D04	compute-disk	d04-autoscale-surface.ts	none published
D04	platform-downtime	d04-resize-down.ts	none published
D05	compute-disk	d05-free-org-autoscale-readonly.ts	none published
D06	compute-disk	d05-free-org-autoscale-readonly.ts	none published
D07	compute-disk	d04-autoscale-surface.ts	none published
D08	compute-disk	d08-storage-type-gate.ts	none published
D09	compute-disk	d09-compute-resize-timing.ts	none published
D10	compute-disk	d10-paid-fill-readonly.ts	none published
D11	compute-disk	curl replay (RUNLOG, 2026-10-01)	none published
I01	instance-sizing	i01-nano-availability.ts	none published
I03	instance-sizing	i03-legacy-pause-lifecycle.ts	none published
I04	instance-sizing	i04-free-org.ts	none published
S01	sfp-platforms	s01-entitlement-sweep.ts	none published
W02	edge-resilience	w02-retry-probe.ts	out/2026-08-16, out/2026-08-17

References

1. Supabase, “Compute and Disk,” Supabase Docs. https://supabase.com/docs/guides/platform/compute-and-disk ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

2. supabase-lab, “Platform-downtime experiment,” supabase-lab runlog. https://github.com/erfianugrah/supabase-lab/blob/d386347/experiments/platform-downtime/RUNLOG.md ↩

3. Supabase, “Cost Control - Spend Cap,” Supabase Docs. https://supabase.com/docs/guides/platform/cost-control ↩ ↩² ↩³ ↩⁴

4. Supabase, “Database Size,” Supabase Docs. https://supabase.com/docs/guides/platform/database-size ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰