# One file for your family

> Your household is its own database file, not rows in a shared table. That is a privacy decision before it is a technical one.

Last updated 19 August 2026

Your household is **its own SQLite file** — not rows in a shared table with a household id on them. Everything you log lives in that one file, and it is the thing export hands over and delete unlinks.

## What the usual shape is

Most applications put every customer in one big database and separate them with a column. It works, and it is the sensible default for most things. It also means every query that reads your data is one forgotten condition away from reading somebody else's, and the only thing standing between two families is that nobody made that mistake — in any query, ever, including the ones written at the end of a long day.

## What baybay does instead

Every household gets a file of its own. Opening your data means opening your file, so there is no shared table to filter and no filter to forget. Another family's records are not one bug away; they are in a different file that the request never opens.

There is a second database, and it is worth knowing exactly what is in it. It holds the account side: which households exist, which email addresses may sign in, live sessions, and rate-limit counters keyed to a hashed address. **It holds nothing you log.** No feed, no sleep, no child's name — those exist only in your household's own file.

## What that buys you

- **Export is a copy, not a report.** The SQLite download is the actual file, not a rendering of selected rows — which is why nothing can be quietly left out of it. [How export works](https://baybay.baby/docs/getting-your-data-out.md).
- **Delete is an unlink.** Deleting a household removes the file. There is no soft-delete flag on a row somewhere, because there is no row somewhere.
- **Moving is moving a file.** Hosted to your own server, or the other way, is one download and one upload. Nothing has to be untangled from anybody else's data first.
- **A backup is per family.** Restoring one household does not mean restoring everyone, and a corrupt file is one family's problem rather than everybody's.

## What it costs

This shape is unusual because it gives up things a single database is good at. There is no cross-family query, so there are no aggregate statistics — nothing that compares your baby's sleep to anyone else's, now or later, because the data to do it is not assembled anywhere. Whether that is a cost or the point depends on what you wanted from a tracker.

It also means the file matters. A family's whole record is in one place, so if you self-host, that is the thing to back up — [the repository ships a script for it](https://baybay.baby/docs/why-there-is-no-docker.md).

## The part that is a promise rather than a design

Isolation between families is structural: it holds because of how the storage is laid out, not because we say so. What is *not* structural is us. On the hosted plan your file sits on a server we run, and someone with access to that server could open it. We do not, and [the privacy page](https://baybay.baby/privacy.md) is the inventory of everything the hosted service holds — but that one is a promise, and it is worth knowing which is which.

The version with no promise in it at all is running it yourself, where the file never leaves your machine — [the code is on GitHub](https://github.com/webdevday/baybay). Both are the same application, and the file is the same file.

---

From [How to use baybay](https://baybay.baby/docs.md). baybay — Feed and sleep tracking for the first year, logged in two taps. Hosted for $7 a month, or self-hosted free on PHP and SQLite with no Docker and no build step. Everything one family logs lives in a single SQLite file they can export or delete.

Canonical: https://baybay.baby/docs/one-file-per-family