CRM with CSV import scaling
CRM with CSV import scaling and launch checklist
A CRM with CSV import stays fast by paginating every list, indexing the main questions, and deferring heavy work until a measured trigger fires. At launch, apply 6 rules, watch 5 signals and hold the performance targets below.
Last checked
Rules to apply at launch
- Pagination: Lists and kanban columns use keyset pagination on an indexed cursor, page size 25 capped at 100.
- Caching: Dashboard counts read per-workspace rollups, cached for 30 s.
- Queues: Imports run as Postgres jobs in chunks of at most 500 rows per transaction, claimed with SKIP LOCKED by capped workers.
- Idempotency: Re-uploading a file is a no-op by (workspace, file_hash); rows are upserted by (job, row_no) and de-duplicated by normalised email.
- Rate limits: Per-workspace limits on uploads, imports in flight and exports; exceeded limits return 429.
- Data growth: import_rows raw payloads purge after 30 days and audit_log partitions by month.
Performance targets
| What to measure | Target |
|---|---|
| Import throughput | 10k rows per minute per worker with per-chunk commits |
| Contact list | p95 < 250 ms, keyset paginated |
| Dry-run preview | p95 < 5 s for a 10k-row file |
What to watch
- Metric import rows rejected ratio: rejected over total rows per import; spikes signal a bad mapping.
- Metric webhook delivery lag s: age of the oldest undelivered outbox row.
- Log import log: job id, chunk, counts, no row contents.
- Slo import completion: 99% of imports under the row limit complete within 15 minutes.
- Alert audit mutation attempt: any UPDATE or DELETE attempt on audit_log is alerted.
Recurring work
- run_import_chunks: runs on import start, then self-continuing. Guard: one transaction per chunk, row limit enforced, resumable by import_rows status, idempotent by (job, row_no).
- deliver_webhooks: runs cron 1m. Guard: outbox claim with SKIP LOCKED, attempt cap and exponential backoff.
Add when the numbers say so
- Read replicas: Serve search and exports from a read replica once primary CPU or search p95 crosses the trigger.
Deferred until it is needed
| Deferred | Adopt it when |
|---|---|
| Two-way sync with external CRMs | paying workspaces request a specific provider. |
| Read replicas for search and export | primary CPU > 60% sustained or search p95 > 500 ms. |
On Forge64
Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.
Every metered resource on Forge64 has a hard cap, so a traffic spike stops at your limit instead of becoming a surprise bill. This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.
FAQ
- When should I worry about scale for a CRM with CSV import?
- Not before a measured trigger fires. For example, for "Two-way sync with external CRMs": paying workspaces request a specific provider.
- What performance targets should a CRM with CSV import aim for?
- Import throughput: 10k rows per minute per worker with per-chunk commits. Contact list: p95 < 250 ms, keyset paginated. Dry-run preview: p95 < 5 s for a 10k-row file.
- Does Forge64 cap my usage costs?
- Yes. Every metered resource has a hard cap, and paid plans add an overage spend cap that you set.
Build your app with Forge64
One prompt to a running app with auth, database, hosting and payments. Start free, no credit card required.
Start building for free