Acceptable Use Policy

Unmetered means you're never charged for usage - every plan is a flat monthly price. To keep shared regions fast for everyone, non-dedicated plans are subject to an Acceptable Use Policy on sustained bandwidth. Properly configured applications won't come near it; it exists to catch runaway clients, not real workloads. On a Dedicated server the policy doesn't apply - the hardware is yours.

Nothing on this page is a bill. Going over an allowance never produces a charge, an overage fee, or a usage invoice. The only consequences are the ones described under If you go over.

Each plan has a sustained-bandwidth allowance per rolling window. These are the published figures:

A dedicated server is single-tenant, so there is no shared region to protect and no acceptable-use bandwidth cap applies. Its practical ceiling is the capacity of the machine you are paying for.

Bandwidth is measured as total transfer in and out, summed across all of your databases on every engine, over rolling 24-hour, 7-day, and 30-day windows. Whichever window trips first drives the policy.

The allowance is per account, not per database. A short spike does not trip anything on its own: the windows are rolling, so what matters is sustained transfer, and a burst is averaged into the window it lands in.

Enforcement is graduated, and it is about stopping traffic, not punishing accounts.

• Over the allowance: you get a 24-hour grace period, a warning email, and a banner in your dashboard. If usage is back under the allowance before the grace period ends, nothing else happens and the warning clears itself.
• Still over when grace expires: the databases on your account are stopped.
• More than 5x the allowance: the databases on your account are stopped immediately, with no grace period. At that level the traffic is actively degrading the region for other customers.

While an account is stopped for acceptable use, restarting is disabled. You resume by upgrading to a plan whose allowance covers your usage, or by contacting us once the underlying traffic is fixed. A database that has been stopped for acceptable use does not restart on its own when the rolling window drains.

Nothing is ever deleted. Stopping is not deletion: your databases, their data, and your backups are untouched and stay exactly as they were. Enforcement only takes a database offline.

The overwhelming majority of AUP violations are unintentional - most often a Redis or Valkey client in a tight poll loop re-reading the entire keyspace many times per second, or clients that open connections without closing them. Fixing these typically cuts traffic by 99% or more and improves your application's latency.

Before upgrading, it is worth checking for a polling interval that reads a whole keyspace instead of subscribing to changes, a client that creates a new connection per request and never closes it, a retry loop with no backoff, or a job that re-reads a full table on every tick. If you would like help finding it, reply to the warning email or contact support and we will look at the traffic with you.

Storage is a quota rather than a meter. Each plan includes an amount, summed across every database on your account: 5 GB on Free, 10 GB on Solo, and 25 GB on Pro, plus 25 GB for each pool block on Pro. Going over never produces a charge, an overage fee, or a usage invoice.

When an account reaches its quota we email you with a grace deadline and the two ways to fix it: delete a database you no longer need, which frees its storage immediately, or move to a plan with more room. If usage is still at or over the quota when the grace window closes, the databases on the account may be stopped until usage comes back under it or the plan changes. As everywhere else on this page, nothing is deleted: your data stays where it is and your backups stay downloadable.

Always-on is a paid feature. A Free database sleeps after 15 minutes without a connection and wakes on the next one; that sleep is what makes the plan free. A Free database is expected to be asleep at least 25% of any rolling 7-day window, which works out to about 6 hours a day averaged over the week.

Anyone actually building on a database clears that line by a wide margin. What does not clear it is traffic whose purpose is to keep the database from sleeping: a poller or cron that hits it around the clock, an uptime or health-check monitor pointed at it, a keep-alive ping, or a deployed application serving requests all day and all night. Those are workarounds for the sleep window, and they are not permitted on the Free plan regardless of how little data they move. If you need a database that stays awake, that is exactly what the Solo and Pro plans sell.

When a Free database is detected staying awake past the requirement, it is put to sleep and may be held asleep, and the warning-then-stop steps under If you go over apply. An account whose traffic is clearly engineered to defeat the sleep window, or that keeps re-establishing it after a warning, may be frozen under the evasion rules below. Nothing is ever deleted, and upgrading lifts the hold immediately.

The Free plan is one account per person or organization. Its limits (database count, storage, and the bandwidth allowances above) apply to you, not to each email address you can register. Creating additional accounts to multiply Free-plan limits, for example to run more free databases than one account allows, is not permitted. If related accounts appear to be operated by the same person or organization, we may ask you to consolidate them into one account, and we may suspend or remove the extra accounts. If the Free plan is too small for what you are building, that is what paid plans are for, and we are happy to help you consolidate first: nothing is deleted, and bob@layerbase.com reaches a human.

We may also suspend or terminate accounts used to work around this policy rather than fix the traffic behind it. That includes creating additional accounts to spread usage across allowances, registering a new account after an existing one was stopped for acceptable use, spreading the same workload across accounts to stay under a per-account allowance, and generating traffic whose only purpose is to keep a Free database from sleeping.

Signups that correlate with an account previously stopped under this policy may be flagged for review. If you were stopped and want to come back, ask us instead of re-registering: we would much rather help you fix the client and keep the account you already have.

The Free plan is for development, testing, evaluation, CI, personal projects, and early-stage products. All of that is fine, and none of it needs a paid plan: building and debugging an application, running a database per branch or per test run in CI, letting a coding agent create and throw away databases, trying an engine before you commit to it, a demo you show a client, a startup that has not launched, a side project, a class assignment, an open-source project.

The line is production revenue. Once a product is running in production and earning recurring revenue, its database belongs on a paid plan. That is the whole test, and it is deliberately not a test of commercial intent: freelancers, contractors, agencies, and companies that have not launched yet are welcome on Free, and building something you intend to sell is exactly what Free is for. There is no clock either. Nothing expires after 30 or 90 days, and an unlaunched product can sit on Free for as long as it takes.

Nothing enforces this automatically. The automatic limits are the ones described above: the bandwidth allowances, the storage quota, the sleep requirement, and the hibernation and archiving built into the Free plan. This clause is not one of them. If usage makes it obvious that a revenue-generating production application is running on Free, a person emails you and asks you to move to Solo ($5/mo). We do not stop, throttle, or delete anything over this clause.

If your situation does not sit neatly on either side of that line - an open-source project with sponsorships, a nonprofit, a side project earning pocket change - email us at bob@layerbase.com. We would rather make an exception than have you guess.

This page covers sustained bandwidth, storage quotas, the Free-plan sleep requirement, and Free-plan usage specifically. The broader acceptable-use rules that apply to Layerbase (no attacking or overloading our systems, no malware or stolen data, no bypassing quotas or billing controls, no reselling Layerbase as a competing managed database service) live in the Terms of Service and apply in addition to this policy.

We may adjust these allowances as the platform and its traffic change. If an allowance is reduced, we will make reasonable efforts to notify affected accounts through the dashboard or email before the change takes effect. Increases take effect immediately.

Questions about this policy, or about a specific enforcement action on your account, can be sent to bob@layerbase.com.