Replit shut down the old shared database. My app is down or missing data. What now?
On June 8, 2026, Replit shut down the older shared development databases that some published apps were still using. If your app was remixed from another app before January 9, 2026, or its DATABASE_URL still pointed at neon.tech, the app may now show database connection errors, start with an empty database, or fail to start. Replit's own warning was plain: update before the date 'to avoid downtime or permanent data loss'.
If you are reading this after the date and the app is down, the first job is to find where the data is. Open the Database panel: if your tables and rows are there, republish with a production database and seed it from development. If they are not, the data lived in the old shared database, and the route is a dump and restore from the old connection string, or Replit support if the endpoint has already been disabled.
Either way, this is a good moment to decide who holds your database. Replit can keep running the app while the database moves to an account in your name, so the next change on Replit's side cannot take your data with it.
In founders’ words
“How can a legacy Neon database originally provisioned by Replit be reactivated, recovered, or exported when it is not visible in the current Database pane and the owner has no separate Neon account?”
“You write the code there, but your single source of truth is GitHub.”
What Replit changed, and when
Replit used to host development databases on Neon, a third-party provider. Under that setup, a remix (a copy of someone else's app, or of your own) could keep using the original app's database connection, and a published app could keep using the development database. Replit's docs describe the problem in their own words: 'Development and production shared the same database, so unintended development changes could affect production apps.'
Two dates matter. Before December 4, 2025, development databases ran on Neon; since then Replit moves them to its own infrastructure, called Helium, automatically when you open the app. And June 8, 2026 is the day the old shared databases were shut down. The migration guide says: 'The older shared database will be shut down on June 8, 2026. Update your published app before then to avoid downtime or permanent data loss.'
You were affected if, in Replit's words, 'Your published app shows database connection errors after the database upgrade' or 'Your app was remixed from another app that had a database before January 9, 2026.' The tell is the connection string: a DATABASE_URL in the published app's Secrets that still contains neon.tech, and matches the source app's NEON_DATABASE_URL.
Source: docs.replit.com/features/data-and-storage/shared-database-migration and docs.replit.com/features/data-and-storage/development-and-production, read on October 2, 2026.
What it means for your app and your customers
If the published app pointed at a database that no longer answers, every screen that reads or writes data fails. Logins fail if users live in that database. Orders, bookings and uploads written since your last copy may be in the old database and nowhere else. The published app's own files are fine; it is the data that is at risk.
The uncomfortable part is that this could happen without you doing anything. The app ran for months, then a legacy endpoint on Replit's side was disabled. Posts in r/replit from June and August 2026 describe exactly that: an app down for a day or two with the error 'The endpoint has been disabled', no unpause button, and a support ticket as the only route. Replit's docs do say the same: production databases and legacy endpoints are managed on Replit's side, and some recoveries need support.
Recovering inside Replit
Replit's migration guide has two cases. Find yours before you touch anything, because the production copy step overwrites what is there.
- Check first. In the source app's Database panel, note NEON_DATABASE_URL (or DATABASE_URL if that is all there is). In the published app, open Publishing, Adjust Settings, Secrets, and read DATABASE_URL. If they match, the published app was on the shared database.
- Case 1: the Database panel already shows your tables and rows. Republish with 'Create production database' on and 'Set up your production database with your current development data' on. Replit sets the published app's DATABASE_URL for you. Replit warns: 'Copying to production overwrites any existing production data.'
- Case 2: the Database panel does not show the data. Dump the old database with pg_dump using the old connection string, remove the old DATABASE_URL secret, restore the dump into the development database with pg_restore, then do Case 1. If the old endpoint is already disabled, you cannot dump it yourself; open a support ticket and say which endpoint and which app. If the database used custom PostgreSQL roles, Replit says the restore can fail and to contact support.
- Afterward, confirm the published app reads and writes, as a new user in a private window, not only as you.
Production databases on Replit are billed by usage through Neon and go idle after five minutes without queries. Point-in-time restore covers 7 days on Core and up to 28 on Pro and Enterprise. Removing a production database is reversible for 7 days and then permanent.
Why this is a good moment to own the database
The shutdown was announced, documented and dated. It still took apps down, because a database you did not create, in an account you cannot open, is not yours to protect. On a database in your own account (a managed PostgreSQL service in your name, or a server you control), nobody retires an endpoint without you, backups run on a schedule you set, and the connection string is yours to hand to any host.
You do not have to leave Replit to get this. Replit's own docs cover connecting an external tool to a database, and a widely shared r/replit post from July 2026 lays out the pattern: code in GitHub, database with an outside provider, Replit as the editor. Moving the whole app is the larger version of the same move. Both are a few days to a few weeks of staged work, and the order matters more than the typing. Our free call reads the app and tells you which version you need, if either.
What a move involves, step by step
- Code. Push the app to a GitHub repository you own from Replit's Version Control tab. From then on the repository is the source of truth, and Replit is one editor among others.
- Database and files. Create a PostgreSQL database in an account in your name (Neon, Supabase, Amazon RDS, or a server you run). Dump from the Replit production database with pg_dump, restore into the new one, and compare row counts table by table. Files in Replit's object storage are copied separately to your own bucket.
- Sign-in and users. If your app uses Replit Auth, users live on Replit's side and do not export as passwords. Set up a login service you control and plan a reset-password email. If users are rows in your own table with hashed passwords, they move with the dump.
- Secrets. Set DATABASE_URL and every API key in the new host's secret store. Regenerate any credential that was in a shared database or a shared remix.
- Payments. Stripe keys and the webhook endpoint move to the new host; test in test mode before the switch.
- Domains and email. Point the custom domain at the new host last. Transactional email from your own domain needs DNS set up early.
- AI providers. Model calls that ran through Replit's integrations become calls on your own provider key.
- Test before switching. Run the new deployment against a copy of the data, click through signup, login, payment and the one thing your product does, then switch DNS and keep the Replit deployment up for a week as a fallback.
When you may not need to move
If your app was created after January 9, 2026, was never remixed, and shows a helium DATABASE_URL, the shutdown did not touch you. If the app has no customers, Case 1 above and a habit of exporting a dump every month is enough. Replit's split of development and production databases, with the Agent unable to touch production, is a real improvement over the old setup.
Move the database when customers depend on it, when you cannot afford a day of downtime while a ticket waits, when a customer asks for backups you control, or when the usage bill for production database compute surprises you. Move the whole app when you have already decided you need tests, staging and a deployment you own.
| What you see | Usual cause | First step |
|---|---|---|
| Published app shows database connection errors since June 2026 | It was still on the shared or legacy Neon database | Compare DATABASE_URL in the published app's Secrets with the source app's NEON_DATABASE_URL |
| App runs but every table is empty | A new production database was created without seeding | Check the Database panel for your data; Case 1 if it is there, Case 2 if not |
| Error 'The endpoint has been disabled' | A legacy Neon endpoint was turned off on Replit's side | Support ticket naming the app and endpoint; meanwhile check for any dump you hold |
| DATABASE_URL contains helium | Already on Replit's current infrastructure | Not affected by this shutdown; keep a monthly dump anyway |
| Users cannot log in but pages load | The users table was in the old database | Recover the data first; passwords come with it if they were in your table |
Questions
Is my data gone for good?
Not necessarily. If the data is in your Database panel, republish with seeding. If it was only in the shared database, a dump from the old connection string recovers it while the endpoint still answers; after that, Replit support is the route. Replit's docs also give production databases 7 to 28 days of point-in-time restore depending on plan.
Why did my app break months after the date?
The June 8, 2026 shutdown covered shared development databases. Posts from August 2026 describe legacy Neon endpoints provisioned through Replit being disabled with no self-service way back. Replit's docs say production databases are managed through Neon and some recoveries need support, so the safe assumption is that any neon.tech connection string you did not create is on borrowed time.
Can I use my own database with Replit?
Yes. Set DATABASE_URL in Secrets to a database you created elsewhere and the app reads and writes there. Replit's Database panel then reports an external database. You keep the editor and the Agent, and the data lives in your account.
Will seeding production from development overwrite my live data?
Yes. Replit's guide warns that copying to production overwrites any existing production data. Only do it when the development database holds the data you want live, and take a dump of production first if it has anything at all.
How long does moving the database take?
Pointing Replit at a database you own is an afternoon if the dump restores clean. Moving the whole app, with login, files, secrets and domain, is a few weeks of staged work with the Replit deployment kept live until the new one has run on real data.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.