Someone asked today whether we could use HubSpot tables as the backend for a client's e-commerce platform.
The short answer is: you can. The better answer is: you probably shouldn't.
HubSpot is excellent at what it's designed for. Contact records, deal pipelines, email sequences, sales activity tracking. It's a CRM. The data model is built around people and relationships and the actions you take on them.
A database is different. It's built around transactions, queries, joins, and integrity. When you need to ask "give me all orders placed in the last 30 days where the product SKU is X and the shipping address is in Ontario" - that's a database question. It has a clean answer in Postgres. In HubSpot, it's a series of workarounds.
The specific issues that surfaced today:
API rate limits. HubSpot's API has request limits. Shopify's API has request limits. When your architecture requires real-time sync between two rate-limited APIs, you've built a system where load spikes translate directly into data lag or errors. There's no buffer. Every query is an API call.
Query limitations. HubSpot tables don't support the kind of complex joins and filtering that operational data requires. You end up pulling large datasets into application memory and filtering in code - which is slower, more expensive, and harder to maintain than letting a proper database do its job.
No transactions. If a write to HubSpot succeeds but the follow-up write to Shopify fails, you have inconsistent state with no clean way to roll it back. Real databases have transactions for exactly this reason.
The instinct behind "use HubSpot as the backend" is understandable. The team already has HubSpot. The data is already there. Why add another system?
Because each system should do the thing it was built for. HubSpot was built to manage customer relationships. Postgres was built to store and query operational data reliably at scale. Using the wrong tool doesn't just make the work harder - it introduces failure modes that compound over time.
The right architecture in this case: Shopify as the source of truth for transactional data, feeding HubSpot for CRM purposes. Not the other way around.
This sounds obvious when you say it out loud. But in practice, "we already have X, can we use it for Y" is one of the most common ways technical debt starts. The answer is almost always: use the right tool, even if it means adding a tool.
The cost of adding a proper database is real but finite. The cost of maintaining a CRM-as-database for two years is open-ended.
TL;DR
- CRMs and databases are built for different jobs. Using one as the other creates API rate limit problems, query limitations, and no transaction support.
- "We already have HubSpot" is not a reason to use HubSpot as your operational data store.
- Use the right tool. The cost of adding it is finite. The cost of the workaround compounds.