# Replit Database Guide: Postgres, Restores, Auth and Costs

> How Replit's PostgreSQL database works: free development copy, billed production copy, 7 or 28-day restores, App Storage, Replit Auth, Clerk and Secrets.

_Source: https://professionalstoolkit.com/articles/replit-database — The Professional's Toolkit · updated November 2026_

---

Every app Replit Agent builds comes with a managed PostgreSQL database, and in practice with two of them. The **development database** is free and capped at 20 GiB per app, or 50 GiB on Pro and Enterprise. The production database runs on Neon and is billed at $0.16 per compute hour plus $0.35 per GiB per month of storage, paid from the owner's credits first. Agent can only read production. Rolling back code never restores production data; that takes a point-in-time restore, with a 7-day window by default, and Pro can choose up to 28 days. Sign-in comes as Replit Auth or Clerk, and keys live in an encrypted Secrets store. The setup protects live data well, provided you know which copy you are touching.


**28 days** — Longest production restore window Pro and Enterprise can choose; the default on every plan is 7 days.



- **20 GiB** — Free development database per app (50 GiB on Pro and Enterprise)
- **$0.35** — Production database storage, per GiB per month, since August 2026
- **$0.16** — Production database compute, per compute hour


## Two databases per app, and why Replit split them

Before July 2025, a Replit app kept its test records and its customers' records in one database. That month Replit launched separate development and production databases in beta for new apps, then moved existing apps over automatically in the following weeks [1]. Today the development copy is created with the app and has lived on Replit's own PostgreSQL infrastructure, called Helium, since December 2025. The production copy is a Neon database that appears the first time you publish, provided development holds data. Both run PostgreSQL 16. Queries behave the same on either side.

The split is about who can touch what. Agent creates and changes tables in development, but it reaches production only through a read-only replica and cannot modify it. Replit's post on secure vibe coding says SaaStr co-founder Jason Lemkin had the Agent delete database data in July 2025, before the separation existed, and Replit says he restored it fully with Rollback. The same post announced a chat-only planning mode, then coming soon, that would not modify the project or its database. **Agent cannot write to your live data.** You still can. That is where the care goes.

## How schema changes reach the live database

Publishing is the only door between the two. On each publish, Replit compares development with production and uses drizzle-kit to generate the SQL that brings production's structure in line: tables, columns, indexes, constraints, views and row-level security policies. That SQL is validated first against a temporary copy of production, and a publish preview lets you test the result in isolation for two hours. Functions, procedures, triggers, grants and domains are not carried over. Anything you created by hand in the SQL console has to be applied to production by you.

Read the data-loss warning before approving. It lists affected tables with row counts, but only for tables that already hold rows in production, so dropping an empty table shows nothing. By Replit's own account, the most common way to lose live data is choosing to add a new column when the change was really a rename: the old column goes, with its contents. An approved migration cannot be recalled from the Publish pane. Some publishes also cause a brief outage, because certain database changes need the app stopped for a moment. A separate option copies development schema and data into production and replaces whatever is there. Use it once, at setup.


> 💡 **Treat renames as renames:** When a publish asks whether a changed column is new or renamed, pick rename if that is what it is. Adding a new column drops the old one with its data.




> ⚠ **A budget can pause the database:** When a Replit budget is reached, all usage-based services are suspended, databases and hosting included, until the next cycle or a higher limit.

## Recovering data: rollback, restore and backups

Checkpoints are easy to misread. They capture files, conversation context, environment and database state, yet a rollback leaves every database alone unless you tick the option to include the development one, which reaches checkpoints up to 7 days old at no separate charge. **Production data is never restored by a code rollback.** The tool for live data is point-in-time restore, on by default with a 7-day window [2]. Pro and Enterprise can choose a window of up to 28 days, and any plan can shorten it to as little as 6 hours or switch it off.

A restore is blunt. It replaces the whole database with its state at the chosen moment, newer rows included, and afterward you can only go further back, never forward. Scheduled daily backups, added in September 2026, form a second layer: off by default, kept 7 days on Core and 7, 14 or 28 days on Pro. A deleted production database sits in a 7-day soft delete and comes back only through Support. Replit says plainly that recovery is not guaranteed. Moving from Pro to Core also cuts any window above 7 days down to 7, so check retention before downgrading. When code and data must match a single moment, Replit's order is:

1. Restore the production database to the chosen time.
2. Roll the project back to the checkpoint from that moment.
3. Publish again.


> ⚠ **Rollback leaves live data alone:** Rolling the project back to a checkpoint never restores the production database. Live data needs a point-in-time restore, which replaces the whole database.


## What the database and file storage cost

Development databases cost nothing. Production is metered, and every line below comes out of the account's monthly credits before any pay-as-you-go charge. These rates apply from the first billing cycle starting in August 2026 or later [3]:

| Item | Rate |
|---|---|
| Production database compute | $0.16 per compute hour |
| Production database storage | $0.35 per GiB per month |
| Point-in-time restore history | $0.20 per GiB per month |
| Scheduled backups | $0.09 per GiB per month |
| App Storage space | $0.015 per GiB per month |
| App Storage data transfer | $0.05 per GiB |
| App Storage operations | $0.0004 basic, $0.005 advanced, per thousand |

Compute runs while the database receives requests and for five minutes after the last one, then idles. Storage keeps billing regardless. It is counted as the monthly peak across every database on the account, and even an empty PostgreSQL database occupies 33 MB. A longer restore window keeps more history, which raises that line of the bill. Paid plans allow up to 100 GiB of production storage, Starter 1 GiB; Starter's monthly cloud credits cover production databases, though no amount is published. Traffic on a published app spends the owner's credits, never the visitor's. Replit's monthly credits ($20 on Core) cover Agent, hosting and databases, and usage beyond them is billed pay-as-you-go unless you set a budget; our [pricing guide](/articles/replit-pricing) has the plan detail.

A budget has a side effect here. It is a hard cap: once it is met, Replit emails you and temporarily suspends all usage-based services, databases included. An unpaid invoice or a usage limit can likewise disable a database endpoint, and the Database pane then shows an Unpause button. A suspension or a disabled endpoint can take a live app offline. Separately, Neon archives a production database after 24 hours without access, and scheduled backups are skipped until it wakes.

## Files, exports and leaving with your data

Images, videos and documents belong in App Storage, Replit's object storage on Google Cloud Storage, because a published app's file system resets on every publish. Each bucket is private and tied to one project; it cannot be attached to another, even in the same account. There are SDKs for JavaScript and Python, and the Google Cloud Storage client library works as well. Three things are missing: lifecycle rules, object versioning and retention policies. Deleting an object or a bucket is irreversible, and every stored object is billed for at least seven days.

Production data is standard PostgreSQL, reachable from any compatible SQL client through the connection string in the database's Settings tab, and it moves to another project with pg_dump and pg_restore. Copying a project does not bring secrets, App Storage buckets or connectors along. Imports carry the same limit in reverse: projects arriving from Lovable, Base44 or Bolt bring their database schema but not the existing data records. Leaked credentials happen. The owner or a workspace admin can regenerate the production password in the Database tool; old strings stop working at once, and the change cannot be undone. Publishing and domains are covered in our [hosting guide](/articles/replit-hosting).


> 💡 **Keep connection strings in Secrets:** Store database and API credentials in Secrets rather than in code or prompts. If one leaks, the owner can regenerate the production password, which cannot be undone.


## Sign-in for your users, and where keys live

Replit ships two login systems. **Replit Auth** signs people in with Replit accounts through Google, GitHub, X, Apple or email on a Replit-branded page; it can be added only through Agent, stores users in a table in your app's database and costs nothing extra. Clerk Auth gives your app its own user accounts, your branding and separate development and production environments, so a test account never exists in production [4]. Clerk is free for now, with usage-based pricing possible later, and has no monthly active user limit. Its dashboard, for MFA and SSO settings, opens only on Pro and Enterprise, and enterprise SSO connections inside an app have been billed since October 2026 at Clerk's pricing, passed through to the Replit bill.

Agent picks Clerk by default on Starter, Core and Pro, and Replit Auth on Enterprise. Replit's advice is Replit Auth for prototypes and internal tools, Clerk for branded or customer-facing apps, and Agent can move an eligible Replit Auth app to Clerk later while keeping its users. API keys go in Secrets, encrypted with AES-256 at rest and exposed to the app as environment variables, though not on Static deployments. Before launch, check the published app's secrets in the Publishing pane. One caution for shared workspaces: members without the Owner role cannot see secret values, yet they can print them as environment variables.


## FAQ

**Can a Replit app use Supabase, Amazon RDS or my own Neon project instead?**

Yes, an app can connect to an external database, but publishing does not migrate it. Schema changes there are yours to apply, since Replit's automatic migrations cover only Replit-managed databases.

**Who on a team can restore the production database?**

On personal apps, the owner and collaborators with edit access. On Workspace apps, members with the Editor, Publisher or Owner role; Read-only members cannot restore.

**Can I edit production rows by hand?**

Production editing has to be switched on manually in My Data, where a SQL console and Drizzle Studio are built in. Replit calls running SQL manually against production an unsupported flow with limited support.

**What happens if I restore a scheduled backup by mistake?**

The database switches to the backup data. The data it replaced is not deleted, but getting it back requires help from Replit Support.


## The bottom line

Replit's database design rests on one idea: Agent experiments on a free development copy while your customers' records sit in a production database it cannot change. That guards against the kind of failure Replit describes from July 2025, but it moves the risk to publish time and to your clicks. Read every migration warning, keep a restore window that matches how fast you would notice a problem, remember that code rollback leaves live data untouched, and set a budget knowing it can pause the database. With those habits, the managed PostgreSQL is a sound home for a small business app.



## Sources

[1] Replit blog: Introducing a safer way to Vibe Code with Replit - Replit — https://replit.com/blog/introducing-a-safer-way-to-vibe-code-with-replit-databases (2026-11)
[2] Replit docs: Data recovery — https://docs.replit.com/features/data-and-storage/data-recovery (2026-11)
[3] Replit docs: Cloud Aug 2026 Pricing Updates — https://docs.replit.com/billing/aug-cloud-billing-updates (2026-11)
[4] Replit docs: Clerk Auth — https://docs.replit.com/features/auth-and-identity/clerk-auth (2026-11)
[5] Replit pricing page — https://replit.com/pricing
[6] Replit documentation — https://docs.replit.com/billing/plans/starter-plan
[7] Replit Terms of Service — https://replit.com/terms-of-service
[8] Replit Privacy Policy — https://replit.com/privacy-policy