The answer was no. Not “no, that’s expensive.” Just no. The jobs weren’t records. Each one was a couple of tags on a contact, three custom fields added at different times by different people, an opportunity someone had dragged into Won, and a note cut off mid-sentence. There was no job. There was a person that a job had happened to.

Nobody made a bad decision to get there. “Can we just add a field for that?” is a five-second request and the answer is always yes, because adding a field is easy. That’s the trap. The CRM never pushes back, so the schema drifts for eighteen months and nobody notices until someone asks a question that needs a join.

This post is about where that line sits: not whether to use the platform, but where GoHighLevel as a database stops being a shortcut and starts being architecture debt. I’ll cover the failure that stays invisible, the four boundaries that decide it, what Custom Objects actually change, and the arrangement I default to when the CRM isn’t the right home.

The failure mode nobody sees coming

Databases push back. Declare a column as a date and it refuses to hold “next Tuesday.” Declare a foreign key and it refuses to orphan the row. Half the value of a schema isn’t storage, it’s the set of things it won’t let you do.

A custom field holds whatever you type. That’s a feature when a rep jots down a competitor’s name. It’s a slow disaster when the field is called contract_value and it contains “1,250.00”, “$1250”, “1250 (pending)” and “ask Dave” across four hundred records.

Here’s why it stays invisible: nothing breaks. Workflows keep firing. Dashboards keep rendering, because they count records rather than summing values. The failure surfaces the day someone needs an aggregate, and by then you have four hundred rows of ambiguity and no way to tell which reading was right. You can’t retroactively decide whether “1250 (pending)” was invoiced.

History is the other half. A CRM field is a current value. Overwrite it and the old one is gone. Anything touching money, entitlements or consent eventually needs to prove what the state was and when, and the platform discarded that silently, months earlier.

What the platform is genuinely good at

An argument against a tool isn’t credible unless it starts with the tool’s real case. GoHighLevel is very good at a specific set of things, most of them expensive to build yourself.

• Conversation state across channels. One thread per person spanning SMS, email and calls, with delivery status attached. Rebuilding that is months of work and a compliance surface you don’t want.
• Sequenced outreach with human interrupts. Wait steps, conditions, and a reply pulling someone out of a sequence. Easy to describe, tedious to get right.
• Tenant isolation by default. Each sub-account is its own location, and nothing crosses unless you deliberately copy it.
• Non-engineers can change it. A workflow a client can edit on a Tuesday afternoon beats an elegant pipeline only you can touch.

Every one of those is about people and communication. That’s the pattern: when the thing you’re storing is a person, or something that happened to a person, the CRM is the right home. When it has a life independent of any person, you’re outside the design.

Four boundaries that decide it for you

“Is this a database?” isn’t a useful question. These four are decidable, and any one of them crossing is usually enough.

1. The question you need to ask requires a join

Not “show me contacts tagged X.” I mean revenue by technician by quarter, or every account with more than three open items where the last payment was over sixty days ago: grouping, filtering across related records, and arithmetic on typed values, all at once. Smart lists answer a narrow, predefined set of questions well, but they aren’t a query engine, and the gap between the two is where most people discover they’ve built a database by accident.

2. More than one system writes the same field

This is the one that quietly costs the most. A stock level or invoice status lives in a CRM field, and both an automation and an external sync can write it. There’s no transaction and no compare-and-set. Last write wins, and “last” is whichever request happened to land second. You see it as an occasional wrong value you can’t reproduce, which is the worst kind of bug to be handed.

The fix isn’t better retry logic. The field has the wrong owner. Exactly one system should write any given piece of state, and if that system isn’t the CRM, the CRM holds a copy for display rather than the value itself.

3. Someone will need the history

Anything where you may later have to prove a prior state needs append-only storage. The workaround people reach for is a note per change. It doesn’t hold: notes aren’t structured, aren’t queryable, and the export path treats them as an afterthought, which leads straight to the next boundary.

4. The exit shape doesn’t match what you put in

People check this last and should check it first. Contact export lands as CSV, and only the most recent note travels with it, truncated to 255 characters. A year of notes exports as one, clipped. Custom object data isn’t part of a direct export at all: the documented route is a snapshot from one sub-account to another, which is a copy inside the platform, not a file you keep. Export permissions are role-gated, so a client who believes they own their data may not be able to pull it themselves.

None of that makes it a bad choice. It makes it a bad sole home for anything you’d be in trouble without.

What Custom Objects change, and what they don’t

Custom Objects are a real improvement and worth using. Properties, policies, vehicles, courses: things that aren’t people, modelled as first-class records with their own fields and associations back to contacts, usable in workflows. For years the only option was squashing everything into a contact, and that was worse. They don’t turn the CRM into a database, though, and the reasons are specific rather than philosophical.

• Ten objects per sub-account, documented as a hard cap. That’s your entire entity budget. Fifteen nouns worth modelling means five go back into custom fields.
• Uniqueness is limited and one-way. Up to ten unique fields per object, and only single line text, multi line text, number and phone types can be unique. It’s enforced across the sub-account and every entry point including the API, which is genuinely useful. But downgrade a unique field to non-unique and you cannot make it unique again.
• Write access is admin-only. Creating, updating and deleting object records is restricted to location admins; regular users are read-only. Check this before assuming the front desk will maintain records.
• Records count against storage quota. Object records and attached files consume the same account storage as everything else, so high-volume machine-generated data is the wrong shape.
• The exit is a snapshot, not an export. Objects, fields and associations move between sub-accounts via snapshots, subject to the same cap in the target account.

Read those as design constraints rather than complaints. They tell you the intended scale: dozens of entity types, no. Millions of rows, no. A handful of business nouns with clean identity and moderate volume, yes, and it works well there.

The API budget is a design constraint too

If you’re treating the platform as a datastore behind an integration, the rate limits shape what’s possible. On the v2 API a marketplace app gets a burst allowance of 100 requests per 10 seconds per resource, and 200,000 requests per day per resource, where a resource means a location or company. Version 1 is end of support, so anything new belongs on v2.

Every v2 request carries a version header alongside the bearer token. It’s easy to forget and produces a confusing failure when missing:

curl -H "Authorization: Bearer $TOKEN" 
     -H "Version: 2021-04-15" 
     -H "Accept: application/json" 
     "$BASE_URL/<resource>?locationId=$LOCATION_ID"

More useful than the numbers is that responses carry their own accounting, so you never have to guess where you are in the window: X-RateLimit-Remaining and X-RateLimit-Max cover the burst interval, X-RateLimit-Daily-Remaining and X-RateLimit-Limit-Daily cover the day.

Pace against the remaining count rather than reacting to failures, and watch the daily counter separately: burst limits recover in seconds, a daily allowance doesn’t, and a backfill that exhausts it takes the rest of the day’s normal traffic with it. The consequence is that polling is expensive and webhooks are cheap. Push where you can; poll only to reconcile.

The shape I reach for: CRM in front, system of record behind

When something crosses one of those boundaries, this is the arrangement I default to. It’s deliberately boring.

1. Pick one owner per piece of state and write it down. Contact details and conversation history belong to the CRM. Money, inventory and anything with an audit requirement belong to the external store. No field gets two owners.
2. Give every record a stable external ID on both sides. Do this on day one. Retrofitting identity onto records matched by email is genuinely painful.
3. Push changes out with webhooks, not polling. Webhook to a queue, queue to a worker, and make the worker idempotent, because you will receive duplicates and you’ll need to replay after an outage.
4. Reconcile on a schedule anyway. Webhooks get dropped. A nightly sweep comparing counts and updated timestamps, re-pulling only the drift, catches what the push path missed without burning the daily allowance.
5. Push a flattened summary back for display. The CRM doesn’t need the ledger, just the two or three values a human wants on the contact record. Treat those fields as read-only and never let a workflow write them.

The external side doesn’t need to be impressive. For a small engagement it’s usually managed Postgres, or plain Postgres on a modest VPS from somewhere like Contabo or InterServer, sat behind Cloudflare so nothing is directly exposed. The glue is often n8n or Make rather than anything custom. What matters is that constraints exist:

CREATE TABLE job (
  id             bigserial PRIMARY KEY,
  crm_contact_id text        NOT NULL,
  technician_id  bigint      NOT NULL REFERENCES technician(id),
  completed_on   date        NOT NULL,
  value_cents    bigint      NOT NULL CHECK (value_cents >= 0),
  created_at     timestamptz NOT NULL DEFAULT now()
);

Nothing clever there. But value_cents can’t hold “ask Dave”, technician_id can’t point at a technician who doesn’t exist, and the quarterly margin question becomes one query instead of a conversation about why it can’t be answered.

Arguments that don’t survive contact

• “We’re too small for a second system.” Sometimes right, and worth taking seriously. But the cost of adding a store later isn’t the store, it’s the reconstruction, and some of that history is unrecoverable.
• “We’ll clean the data up later.” Cleanup needs to know what the value should have been. Free-text fields with no history don’t retain that. This is the one I’d push back on hardest.
• “Custom Objects solved this.” They solved modelling non-person entities, which was the biggest gap. They didn’t add joins, transactions, versioning or an export path.
• “The client wants everything in one place.” They want one place to look, which is a UI requirement, not a storage requirement. A summary pushed back to the contact record satisfies it.
• “We can export whenever we want.” Test it before you rely on it. Export the notes. Export a custom object. Do it as the client’s own user, not as an admin.

How I’d decide

1. Name the thing. If it’s a noun that isn’t a person, it wants to be a record, not a field on a contact.
2. Write out the hardest question anyone will ask of it. The actual sentence. If it needs grouping, arithmetic, or two entity types at once, the CRM isn’t the home.
3. Count the writers. More than one system writing the same field means the CRM holds a copy, not the value.
4. Decide whether history matters. Assume it does for anything involving money or consent.
5. Do the export before you commit. Not the docs, the actual file. Whatever doesn’t come out cleanly is data you don’t really own.
6. Check the entity budget. Ten objects per sub-account. If you’re modelling toward that ceiling, decide now which nouns get a slot.

Steps two and five take about twenty minutes together and prevent most of what I’ve described.

Frequently asked questions

Can I use GoHighLevel as a database for my business data?

For people, conversations, bookings and pipeline state, yes, and it’s a good one. For anything needing joins, transactions, versioned history or guaranteed export, no. Using GoHighLevel as a database for that second category works right up until someone asks a question the platform can’t express, and by then the data is already ambiguous.

How many Custom Objects can a sub-account have?

Ten per location, documented as a hard cap. Each object supports up to ten unique fields, and only single line text, multi line text, number and phone types can be marked unique. Treat those slots as a fixed budget when you plan the model.

Can I export Custom Object data out of the platform?

Not through a direct export the way contacts go to CSV. The documented path is a snapshot between sub-accounts, which carries fields and associations but stays inside the platform. The API does support CRUD on objects and records, so a scripted pull is the practical route to a copy you keep.

Why do my exported notes look truncated?

Contact export includes only the most recent note, cut to 255 characters. That’s expected behaviour, not a bug. If notes hold anything you’d need later, pull them through the API and store them somewhere that keeps all of them.

What usually trips the API rate limits?

Backfills, and polling loops that scale with contact count. The limits are 100 requests per 10 seconds and 200,000 per day, both per resource. Read the rate limit headers on each response and pace against them rather than retrying into a wall.

Does a sub-account count as a real tenancy boundary?

For operational separation, yes: each is its own location and nothing crosses unless you copy it. The consequence is that cross-client reporting has to happen outside the platform, because no query spans locations. If portfolio-level reporting is a requirement, plan for an external store from the start.

Should I migrate off the CRM entirely?

Usually not. A full migration means rebuilding the conversation and outreach layer, which is the part it does best. Moving one category of data out, with a clear owner and a summary pushed back for display, is smaller and reversible.

The one thing worth remembering

The CRM will never tell you that you’ve gone too far. There’s no constraint to violate, no error to raise, no migration to fail. That’s exactly what makes the boundary worth drawing on purpose, before the field gets added rather than after four hundred records have been through it.

The test I’d keep: write down the hardest question anyone will ever ask of this data, then check whether the platform can express it. If it can’t, that’s not a reporting gap a better dashboard will close. It’s the boundary telling you where GoHighLevel as a database should stop and a real system of record should start. The identity mapping, the webhooks, the reconciliation sweep: all of that is plumbing once the decision is made.

Working on this with me

Most of what I do here is unglamorous and ends with the reporting question getting answered:

• Auditing an existing setup and mapping which custom fields have quietly become load-bearing, with an owner assigned to each.
• Drawing the boundary: what stays in the CRM, what moves to Custom Objects, what needs an external system of record.
• Building the sync layer: webhooks into a queue, idempotent workers, stable ID mapping both ways, and a reconciliation job that catches dropped events without burning the API allowance.
• Standing up the store: schema design with constraints that hold, on managed Postgres or a small VPS, with backups you’ve tested restoring rather than assumed.
• Rescuing free-text fields into typed columns, including the judgement calls about what’s recoverable.
• Handover packaging: a real export, documented, so a client can leave with their data whether or not they keep working with you.

If you’re weighing this up, send me something concrete: a list of your custom field names, a sample export, or the query you can’t currently answer. That’s usually enough to tell you where the line sits.

The post Your CRM Is Not a Database: Where GoHighLevel Should Stop appeared first on John Nessime.