Limits, and what is not built

This page is the one to read before you put anything you care about in SnoutData Cloud. It says what each plan actually gets, what pauses and what that costs you, what we protect against, and what we do not.

note

SnoutData Cloud is in private testing. Numbers here come from the plan rows the service runs on and from measurements taken against the live system. Where a figure has not been measured, this page says so rather than estimating.

What each plan gets

Per project, unless the row says otherwise.

	Free	Plus	Pro
Projects	1	2	5
Storage	500 MB	8 GB	20 GB
Connections	50	100	200
Memory	512 MB	1 GB	2 GB
CPU	0.5	1.0	2.0
Idle projects	paused after 7 days	never paused	never paused
Backups kept	7 days	7 days	14 days
Point-in-time restore	no	no	7 days
Deleted projects kept	7 days	7 days	7 days
Mark a project production	no	yes	yes
REST and GraphQL data API	no	yes	yes

Auth, storage, realtime and edge functions are on every plan, including free. The data API is the exception, and the reason is cost rather than packaging: it is a server per project that runs whether or not anyone calls it, and on a free project it would cost more per month than the database does. A free project asking for it is refused with a sentence about the plan, not an error.

Every plan also keeps at least two full backups whatever the retention row says, plus the continuous write-ahead log stream between them. A full backup is taken at most every 24 hours.

A free project is the one that gets paused and then evicted, which means its data lives only in the backup store until you come back to it. That is why it is retained for seven days like a paid one rather than for less: a wake is a restore, so the backup is not a copy of a free project, it is the free project.

Memory and CPU are caps, not reservations: they are what the container is limited to, so a runaway query in one project cannot take a machine down for everybody else on it. They are read when the database starts, so a plan change takes effect when the project is next recreated, not instantly.

Storage: over the limit means read-only

A project that grows past its plan's storage goes read-only. It is never refused and never deleted.

Reading keeps working. Writing returns cannot execute INSERT in a read-only transaction until the database shrinks or the plan changes. The decision is made when a size measurement arrives, and the host samples every fifteen minutes, so there is a short window where the plan says one thing and the database is still doing the other.

snoutdata usage warns at 80% and says plainly what happens at 100%. snoutdata db url prints a warning to stderr, and projects list shows read-only instead of ready.

Pausing and waking

Only Free projects pause. Plus and Pro never do.

A Free project with no connection for 7 days is backed up and stopped. Idleness is measured from the last connection, or from when the project was created if nothing has ever connected to it. A project marked production is never paused, and a project that is mid-create, mid-restore or in error is left alone.

After a further 2 days paused, the data directory is removed from the machine and object storage is the only copy. Nothing you asked for and nothing you are told about: it is our storage decision, so we make it quietly.

That is the difference between the two kinds of wake:

	What it is	Measured
Warm wake	The data is still on the machine, so it is a start.	1.1 s at 100 MB, 1.4 s at 500 MB
Cold wake	The data is only in object storage, so it is a restore.	about 10.5 s at 100 MB, about 15 s at 500 MB

Both were measured from the host, in region. A separate measurement of the whole path, taken on 2026-09-05, reads 10 seconds at 8 MB and 21 seconds at 172 MB for the restore itself, and about 22 seconds at every size for a resume driven by a client, which adds an API round trip and the host's next poll to the same restore.

Connecting to a paused project wakes it, and the client waits. The CLI says so before it happens.

Durability

Your database lives in object storage in us-west-2 on AWS. A server is a cache: losing one loses uptime, not data.

What we protect against, and what makes each one true:

• A mistake of ours cannot destroy your data for seven days. Every version in the backup store is locked against deletion by S3 itself, including against us. This has been on since 2026-09-05; objects written before that carry no lock, which is the documented limit of it.
• A backup that would not restore is found before you need it. Every project is restored into a throwaway server on a schedule, its tables counted, its heaps and indexes checked against each other, and the stored files compared with the checksums taken when they were written.
• A deleted project can be brought back, for the grace period on your plan, before anything is erased.
• Losing a server loses nothing. A project is restored from object storage whenever it needs to be.

The most you could lose is about 56 seconds of writes, measured on 2026-09-05, and only while the database is taking writes. An idle database rolls no write-ahead log segment and has nothing to lose. The bound the design gives is a segment switch every 60 seconds plus up to 30 seconds to push it.

What we do not protect against

These are the honest gaps, not a roadmap.

• Our cloud account going away. Both copies of your backups live in the same AWS account that runs the service. There is no replica in an account we do not control, so this is the one failure the arrangement below does not cover.
• Losing more than about a minute of writes. Writes reach durable storage within roughly a minute of being committed. A server lost inside that window loses what had not yet been written out.

Cross-account replication and customer-managed encryption keys are not built.

What a region failure costs

There is a second copy, in us-east-1, since 2026-09-11. Every backup written in us-west-2 is replicated there continuously by the storage service itself, so there is no schedule to miss and nothing of ours in the path. A deletion is not replicated: removing a file from the first copy leaves the second one holding it.

And it has been restored from, not merely written to. On 2026-09-12 every project in the region was brought back out of the second copy into throwaway servers, replayed to the end of its write-ahead log, and checked table by table against its own indexes. Eight of eight, in 261 seconds, roughly 20 seconds each. The exercise is a script we re-run after anything that changes how backups are written, rather than a paragraph.

What it does not buy you: a region failure is still an interruption. Bringing a project back into a healthy region is minutes of work by a person, not a switch that throws itself.

Point-in-time restore

Pro only. It restores into a new project, never in place, and reaches any point in the last 7 days.

One thing worth being clear about, because it is easy to assume the opposite: the recovery point does not vary by plan. A cold wake replays to the end of the archive whatever you pay, so every plan loses the same amount. What Pro buys is the ability to choose a moment, which answers "put it back to before I ran that", not "lose less".

Deleting a project

A deleted project's data is kept for the grace period on your plan (7 days on every plan today) and is then erased permanently.

A free project is free for as long as it is up. There is no clock on a project you are using, and nothing here expires a project for being old.

The clock starts at idleness. A free project nobody connects to is paused, then evicted, and its data then lives in the backup store. It is kept there for 180 days from the day it goes cold, and coming back at any point in that window restores it.

After that it is archived, not deleted. It moves to cheaper, slower storage and it is still yours. Nothing in this ladder erases a database. The only thing that does is you asking us to, and even then it is recoverable for the grace period on your plan first. (The archive step is not built yet, so today a cold project simply stays where it is.)

A paid project stays up for as long as it is paid, with no pausing and no idleness clock. If a subscription lapses, the account returns to the free rules above, including free's storage cap: a database larger than the free limit is made read-only rather than paused or removed, and becomes writable again as soon as the plan or the size does.

Where a project can live

--region defaults to us-west-2, and that is the only region with a machine and a storage cohort in it today. More regions are not built.

Security, in plain sentences

• Each project runs as a rootless container of its own, with its own data.
• Connections are TLS only, through a proxy that terminates TLS for *.db.snoutdata.com and routes on the name.
• Your project's database password is stored encrypted, wrapped by a key management service and decrypted only in the one function that serves it to you.
• Backups are restore-tested on a schedule, not merely taken.
• Everything that changes a project is on the audit log, whether it was you, the CLI, an agent or us. You can read it in the dashboard.

And the part a hosted database cannot honestly claim otherwise: we hold your database password. A hosted database is held by its host, and our terms of service are what bind us, the same as every other cloud. If you want credentials that never leave your machine, that is the SnoutData desktop app, where they never do.

Not built

Named here so you do not go looking:

• snoutdata sql, a statement runner in the CLI. Deliberately absent until it goes through the engine's guard.
• Branches, read replicas, larger compute sizes, and more regions.
• A domain of your own on a project. Every project answers at <ref>.db.snoutdata.com and <ref>.api.snoutdata.com, and pointing your own name at one is built but has never issued a real certificate, so it is not offered.
• Scoping an access token to particular projects. A token is exactly as capable as the person who made it, which is right for a first version and wrong for a build server that only needs one database.