Troubleshoot databases

Identify the affected database

In the Database pane, check whether the problem affects development or production. Compare this with the environment running the failing request. See Development and production databases. Check Replit Status for a matching incident. Do not infer an outage solely from a connection error.

“The endpoint has been disabled”

Check for an outstanding billing issue or usage restriction.
Open the Database pane and select the affected environment.
If Unpause database is available, select it, then retry the connection.
If the control is missing, check whether a manually configured DATABASE_URL points to a different database than the one shown in the pane.

Compare connection settings privately. Do not print or share the full connection string. Do not remove an intentional external-database configuration. If unpause fails, or the control is still missing, contact Support with the environment, error, and steps attempted. Repeated restarts are not a substitute for investigating a paused database.

Preview connects, but the published app does not

Check the published app’s production secrets and database configuration, especially after a restore or migration. Workspace secrets alone do not verify the production connection. In Publishing, review Adjust settings and the production secrets. If your app uses both DATABASE_URL and individual PostgreSQL variables, ensure they refer to the same intended database. Save and publish the intended configuration, then verify a read before testing writes. Never copy production credentials into frontend code or a public repository.

Tables or records are missing

First verify which database the app is reading. An empty development database or a different connection target can look like data loss. Check whether a recent migration changed table names or schema. Publishing app code does not establish that development records were copied to production. Do not run a reset, drop tables, or copy development data over production as a diagnostic step.

Unsupported database objects

Replit uses drizzle-kit, the migration tool for Drizzle ORM, to manage your databases at two points:

In development, Agent updates your Drizzle schema file and runs drizzle-kit to apply it to your development database.
When you publish, Replit compares your development database with your production database and generates the SQL needed to bring production up to date. It compares the databases themselves, not your schema file.

Drizzle-kit only works with what a Drizzle schema can describe: tables, columns, indexes, constraints, enums, sequences, views, and row-level security policies.

Not supported

These objects aren’t part of a Drizzle schema, so drizzle-kit can’t compare or create them in development, and publishing doesn’t copy them to production:

Domains, custom types created with CREATE DOMAIN.
Functions, procedures, and triggers.
Grants, table permissions given with GRANT.

Limited support: roles

Drizzle can declare roles, but support for them is limited. Therefore publishing doesn’t create, change, or remove roles currently.

Objects created with SQL

You can create any of the unsupported objects above manually via the SQL console or Agent can also run SQL directly on your development database. They will work in development and Preview, but any unsupported objects will not be copied to production on publish.

What happens when an object isn’t supported

If a table, view, default, or policy depends on one of these objects, publishing stops at the database migration with an error such as:

function my_function(text) does not exist
type "my_domain" does not exist
role "app_user" does not exist

Replit rolls back the failed migration, so your production database isn’t changed. Triggers and grants usually don’t cause an error. Publishing succeeds, but your published app may behave differently from Preview. For example, a trigger that updates a timestamp doesn’t run in production. To fix either case, find what’s missing and apply it to production, then publish again.

Find what’s missing in production

Agent can run this comparison for you, because it has read-only access to your production database. See the prompt in Apply missing objects to production. To check it yourself, run the same read-only queries on both databases from the SQL console, then compare the results:

-- Functions you created (excludes functions installed by extensions)
SELECT p.proname FROM pg_proc p
WHERE p.pronamespace = 'public'::regnamespace
  AND NOT EXISTS (
    SELECT 1 FROM pg_depend d WHERE d.objid = p.oid AND d.deptype = 'e'
  )
ORDER BY 1;

-- Triggers
SELECT DISTINCT event_object_table, trigger_name
FROM information_schema.triggers
ORDER BY 1, 2;

-- Domains
SELECT typname FROM pg_type
WHERE typtype = 'd' AND typnamespace = 'public'::regnamespace
ORDER BY 1;

-- Roles
SELECT rolname FROM pg_roles
WHERE rolname NOT LIKE 'pg\_%'
ORDER BY 1;

-- Grants to roles other than the one you're connected as
SELECT table_name, grantee, privilege_type
FROM information_schema.role_table_grants
WHERE table_schema = 'public' AND grantee <> current_user
ORDER BY 1, 2, 3;

Anything that appears only in development needs to be applied to production. Some roles are created by Replit and differ between the two databases; you only need the roles your app’s policies or grants use.

Apply missing objects to production

Advanced: these steps run SQL directly on your live production database to add objects Publishing doesn’t carry over, like functions, triggers and roles. Running SQL manually is an unsupported flow that we can only help with in a limited way, so we recommend it only if you’re comfortable working with SQL.Review your options in Data recovery first, and apply changes when your app has little traffic.

Ask Agent to compare your databases and write a script for anything missing. Paste this prompt into Agent in your project: Agent can read your production database but can’t change it, so you run the script yourself in the next steps.
In the Database tool, select the production database, open My Data, and turn on Enable Editing.
Open the SQL console and run the script.
Turn off Enable Editing, then publish again.

Publishing doesn’t remove these objects, so they stay in place for future publishes. Keep the script in your project and run it again whenever you add or change one of these objects in development.

Data was deleted or overwritten

Stop avoidable writes to the affected data while evaluating recovery. A restore can replace newer data. Preserve the current state and understand the scope before confirming a recovery action.

Record the affected environment, approximate last known good time and timezone, and what changed. Check the recovery options and available history shown for that database. Retention and recovery methods depend on the database and configuration; do not assume an older timestamp is recoverable. Use the database-specific instructions in Data recovery. Do not assume that rolling back app code also restores production data. Contact Support if you cannot identify a safe recovery path. Recovery is not guaranteed, and increasing retention cannot recreate history that was not kept.

Credentials may have been exposed

Remove exposed values from shared material. For a supported production database, regenerate its credentials in the Database tool. Review the eligibility requirements and interruption warning first. Update external clients with the new connection string. If the action isn’t available, contact Support. Do not delete the database to rotate credentials.

Details for Support

Include the project URL, environment, sanitized error, time and timezone, recent migrations or restores, and checks already completed. Do not include database credentials, full connection strings, or customer records. See the support checklist.

​Identify the affected database

​“The endpoint has been disabled”

​Preview connects, but the published app does not

​Tables or records are missing

​Unsupported database objects

​Not supported

​Limited support: roles

​Objects created with SQL

​What happens when an object isn’t supported

​Find what’s missing in production

​Apply missing objects to production

​Data was deleted or overwritten

​Credentials may have been exposed

​Details for Support

Identify the affected database

“The endpoint has been disabled”

Preview connects, but the published app does not

Tables or records are missing

Unsupported database objects

Not supported

Limited support: roles

Objects created with SQL

What happens when an object isn’t supported

Find what’s missing in production

Apply missing objects to production

Data was deleted or overwritten

Credentials may have been exposed

Details for Support