How much database storage does my data need?

About 1.8 million narrow rows per GiB, and far fewer rows with text in them

A narrow, indexed row costs about 600 bytes all-in, indexes included. We measured that on WattleDB’s own production tables on 21 September 2026. A row that carries text costs about 600 bytes plus one byte per character, so a record with a 1,500-character note is about 2,100 bytes. One GiB is 1,073,741,824 bytes, which holds about 1.8 million of the narrow rows or about 510,000 of the rows with a note.

Two things come off the allowance before your data does. An empty database already uses about 16 MB (15.8 MiB) for PostgreSQL’s catalogue and the extensions we install. And PostgreSQL needs working room for housekeeping, so plan to fill about 80% of the allowance, not all of it. That gives the figure every table on this page uses:

Usable = 80% of the allowance, less the 15.8 MiB an empty database uses. Hobby: 80% of 1,024 MiB is 819.2 MiB, less 15.8 MiB is 803.4 MiB. Allowances are per database and are binary units (1 MiB = 1,048,576 bytes, 1 GiB = 1,073,741,824 bytes); the pricing page writes them as MB and GB. Free is one database per workspace and pauses after seven idle days, so it suits development rather than a live app. Every figure below is typical, and yours will differ with your schema.

Storage is one input. For clinical or participant records, choose the plan for its backups, recovery window and per-person access first. Hobby and Launch can restore the database to any point in the last 7 days and Scale the last 30; Hobby is one person per workspace, while Launch and Scale let you share with up to 5 and 20 people. The pricing page has the detail.

Typical yearly growth, by sector

• A SaaS booking product with 20,000 users grows by about 1,040 MiB a year, most of it audit rows.
• A small agency client app grows by about 4.4 MiB a year.
• An NDIS provider with 150 participants grows by about 54 MiB a year.
• A 90-bed residential aged-care home grows by about 500 MiB a year.
• A bookkeeping practice with 300 clients that stores bank transactions grows by about 436 MiB a year.
• A 10-lawyer firm’s database grows by about 35 MiB a year, and its documents by about 9.2 GiB.
• A four-GP practice grows by about 305 MiB a year.
• A 3-dentist practice grows by about 78 MiB a year, after about 118 MiB up front.
• A four-physio allied-health clinic grows by about 110 MiB a year.

Users, orders and the audit trail that outgrows them

Most SaaS tables are narrow. What fills a SaaS database is usually the event or audit table, because it gains a row every time anyone does anything.

For the privacy law that applies to SaaS teams and what you still have to do yourself, see Industries: SaaS builders & SMBs.

Many small client databases, where the baseline matters more than the data

An agency usually runs one database per client. Each client’s data is small; the thing to count is how many databases you run.

For who the customer of record is and what you pass on to clients, see Industries: Agencies & freelancers.

Participants, shift notes and incidents

Participant and resident profiles are a rounding error. Progress notes are the bulk, because one is written for every shift or every resident on every shift.

For the practice and quality standards and what you still have to do yourself, see Industries: NDIS, aged care & community services.

Clients, ledger lines and BAS workpapers

Whether you store transaction lines decides almost everything. A practice tool that holds clients, jobs, time and workpapers is small. Software that keeps every bank line is not.

For the rules that apply to tax practitioners and where we are not the right fit, see Industries: Accounting & bookkeeping.

Matters, time entries and documents

A law firm’s database is modest. Its documents are not, so for legal work the file allowance usually decides the plan.

For confidentiality duties and what we can say about access today, see Industries: Legal.

Patients, appointments, clinical notes and results

A patient’s demographics are one row. Their history is many: every appointment, note, prescription and result adds to it, so a practice’s database grows with its consults rather than its patient count.

Dental

Dental software adds a tooth chart per patient and treatment plans, on top of the patient, appointment and note rows above. X-rays are files, not rows: see files.

Allied health

Physiotherapy, psychology, podiatry and similar practices use the patient and appointment rows above, with a session note per consult and programmes for some patients.

For health privacy obligations, what WattleDB provides and where we are not the right fit, see Industries: Health software.

Files: scans, PDFs, photos and X-rays

Every database comes with a private S3-compatible bucket. Files are measured differently from rows, and the object storage quota is a hard limit: once the bucket is full, new uploads are refused. There is no 80% rule here, but there is a catch that uses space you cannot see.

Deleted and replaced files still count for 30 days. A bucket keeps older versions of deleted and overwritten files for a 30-day recovery window, and those versions sit inside your quota. A file you delete keeps using space until its 30 days are up. A 3 MiB photo replaced every day keeps about 30 older copies, around 90 MiB, at any one time. If your app overwrites or deletes files often, allow for that churn.

Counts assume nothing has been deleted or replaced in the last 30 days. Per GiB = 1,073,741,824 bytes divided by the file size, rounded; whole studies are rounded down.

Know what the bucket is for. It is served from Sydney, with a cross-state copy in Melbourne that we restore from. That copy holds current versions only and is not an endpoint you can reach, so it guards against losing Sydney rather than against deleting a file. Object storage is outside the SLA. The backups and point-in-time recovery on our plans cover your PostgreSQL database, not the bucket. Use the bucket for uploads, working copies, generated exports and previews, and keep your own master copy of anything you cannot re-create. Imaging archives in particular, CT studies above all, outgrow these allowances quickly.

The method, so you can check it or redo it for your schema

• The measurement. On 21 September 2026 we measured WattleDB’s own production tables: a narrow, indexed row costs about 600 bytes all-in, including its share of the table’s indexes and PostgreSQL’s per-row overhead.
• Rows with text. We add one byte per character of text on top of the 600. That is close for plain English. Characters outside basic Latin take two to four bytes each in UTF-8. PostgreSQL compresses long values once a row passes about 2 KB, and we do not count that saving, so long English notes usually land smaller than our figures, not larger.
• Records made of several rows (an order with line items, a tooth chart, a treatment plan) are counted as the sum of their rows at about 600 bytes each.
• What counts toward the plan. The database allowance counts the database’s own size as PostgreSQL reports it with pg_database_size: tables, indexes, and large values PostgreSQL compresses and stores out of line. Write-ahead logs and backups are not counted. The object storage allowance counts every file in the bucket, including older versions kept for the 30-day recovery window.
• The baseline. An empty database uses about 16 MB (16,537,267 bytes, or 15.8 MiB, when measured on 8 September 2026) for PostgreSQL’s catalogue and the extensions we install. It counts toward the allowance, so we take it off first. See the FAQ for the breakdown.
• The 80% rule. PostgreSQL does not overwrite a row in place. An update or delete leaves the old version behind until vacuum clears it for reuse, so a busy table always carries some dead space. Leave roughly a fifth of the allowance free for that housekeeping. Usable = 80% of the allowance less the baseline.
• The arithmetic. Records per GiB = 1,073,741,824 bytes divided by the record size. Records per plan = the plan’s usable bytes divided by the record size. Years of room = usable space, less what you store up front, divided by what you add each year. Everything is rounded to two significant figures and labelled typical, because it is.

Where these figures will be wrong for you. A table with many indexes, or with a full-text or trigram index over long text, costs more per row. So do wide rows with dozens of columns. A large JSON document in each row adds roughly its own size, less whatever PostgreSQL’s compression saves. An embedding from a 1,536-dimension model is about 6 KB on its own, before its vector index. Files stored inside the database instead of in the bucket count at their full size against the database allowance.

Want your own number? Send a sample schema, or the output of pg_dump --schema-only, with rough row counts to support@wattledb.com.au. We will measure it and tell you which plan fits. If you already have the data in PostgreSQL, SELECT pg_size_pretty(pg_database_size(current_database())); gives you the same figure we count.

Scale is the largest plan you can buy online. If one database needs more than Scale’s usable figure, email support@wattledb.com.au with your estimate before you sign up, and we will tell you plainly whether we can host it.