My app has ~990 PostgreSQL tables (enterprise ERP). Deployment page shows “Failed to check for database diff: Maximum call stack size exceeded” and I can’t republish. Tried removing drizzle.config.ts and the .drizzle folder — no change. App works fine in dev. Is there a way to bypass the database diff check?
I haven’t seen this one, my app never crossed 190 tables so you’re hitting the upper limit. It might be time to go straight to Supabase or do a custom setup with replit to handle your larger database. You’ll also end up blowing through the 10gb per month database limits fast so I would figure out what kind of read/write you’re going to be getting on the database, I have 600k live diamonds with over 1.4 millions total (including archived entries for historical purposes) and I had to implement multi-level caching to avoid the huge database hits once traffic spiked on our search. If you have a company of hundreds of employees hitting this all day long it will need a local database server to avoid paying for the load most likely, or a healthy budget for the computational cost.
Hi Jeff, thanks for the insight — really appreciate you taking the time.
You’re spot on about hitting the upper limit. We’re running a full enterprise ERP with ~990 tables across 46+ modules (HR, Payroll, Procurement, Manufacturing, Construction, ITSM, Asset Management, and more), so we’re well beyond the typical Replit project scope.
Good to know about the 10GB database limits — our production database is already on Neon so we’re not relying on Replit’s built-in DB for that. We’ve also got multi-tier caching in place, which sounds similar to what you’ve done with your diamond search.
Your point about Supabase or a custom setup is interesting. If you have any tips on configuring the deployment to skip the database diff check entirely, I’d love to hear them. That seems to be the core blocker right now.
Thanks again — and 600k live diamonds sounds like an impressive platform!
Patrick
I am just one person, so I build my system to make sure it stays within the monthly limits with caching. It has worked well so far, I’m under $90 of usage per month on actual infrastructure including backups, 3gb database so far. I expect in about a year’s time I’ll outgrow it with analytics and other historical diamond data etc but I will cross that bridge when I get there.
Neon is good, if you already have a direct account with them, limits aren’t an issue, just cost management. You might need to do some predictive models on Claude or ChatGPT based on any data you can feed into it from your current ERP systems and estimate volume and see if it’s worth just staying on Neon or if the infra costs will get insane and maybe just build a local database server. If it’s all under one roof this is the most cost effective way, if you have several locations and people all over the place not on the same network then it gets more complicated but still doable. This will have to be something to go over with the tech / IT team (unless that’s you). I actually don’t use Supabase, but I have heard good things and it seems to be the direction people go when they surpass the Replit included limits. You’ll have to weigh the pros and cons, the more infrastructure you put in place are also pain points and there are other costs and risks involved if it will involve bringing in other people to help manage that. Are you importing data from another system like Oracle or SAP or something?
Also, I did some digging on your deployment blocker after our conversation. The “Maximum call stack size exceeded” error is happening in Replit’s internal deployment pipeline — they use a forked version of Drizzle Kit to generate a diff between your dev and production schemas at deploy time. The diff engine recursively walks all tables, foreign keys, indexes, and constraints to build JSON snapshots for comparison. At 990 tables with all the cross-references an ERP would have between 46+ modules, that recursive traversal is blowing past Node’s call stack limit. The same issue has been reported in Supabase’s CLI with their schema inspection library — it’s a known pattern when schemas get large enough.
Some options worth looking into:
-
Open a ticket with Replit support directly. Since you’re already on Neon externally, the ideal outcome is them letting you skip the database diff check entirely. There’s no documented way to bypass it — it’s baked into the deploy process — so this needs to come from their side.
-
If your 46+ modules are all in one Postgres schema (public), try splitting them into separate Postgres schemas per module or module group. Drizzle supports a schemaFilter config option that could reduce the scope of what the diff engine has to crawl through at once.
-
Manage migrations externally. Since you’re already on Neon directly, you could run Drizzle Kit migrations yourself outside of Replit’s pipeline (or use Alembic, or plain SQL scripts), and treat Replit deployments as app-code-only. This means disconnecting from Replit’s managed database feature but gives you full control.
-
If none of the above work, you may have outgrown what Replit’s deployment pipeline was designed for at 990 tables. Railway, Render, or a VPS with your existing Neon setup would give you a deployment process that doesn’t choke on schema size.
Hope that helps unblock you. Let me know how it goes.