Follow one client request through a portal. The request itself is a record. So are the three replies, the two attachments, the approval from a manager and the history of who changed its status and when. Six months later someone will want to know how long requests like it took, and a compliance officer may want every message in the thread.
On HubSpot, every one of those records has to live somewhere designed for marketing.
Where does a HubSpot portal store its data?
In one of two places, because HubSpot has no application database to offer. The first is HubDB, a table store built to feed web pages. The second is the CRM itself: tickets, custom objects and associations, reached through HubSpot’s API. Most custom portals end up using both, with the CRM API holding them together.
Each works for what it was designed to do. Neither was designed to be the system of record for how a firm serves its clients.
Is HubDB a database?
Not the kind a portal needs. HubSpot calls it “HubSpot’s native database tool” and describes it as rows, columns and cells, “much like a spreadsheet.” We were less careful: in 2024 we called it “HubSpot’s robust relational database” in a guide that’s still on this site. 1 Source 1 Lynton, “10 Ways to Use HubDB for Your HubSpot Website,” May 11, 2024 (lyntonweb.com/inbound-marketing-blog/hubdb), which called HubDB “HubSpot’s robust relational database.” HubSpot Developers, “HubDB,” read October 31, 2026: “HubSpot’s native database tool,” storing data “in rows, columns, and cells, much like a spreadsheet”; “All new tables created are set with a status of draft”; “only published HubDB content will appear on the live page”; “HubDB tables can be joined using the Foreign ID column type.”
What HubDB does well is feed pages. Team directories, resource libraries, location finders, event listings: content an editor maintains and visitors read. It can join one table to another, and changes are made in a draft and go live when the table is published. That’s a sensible cycle for web content. It’s an odd one for a record a client submitted a second ago.
The limits follow the same design. A table holds 10,000 rows and 250 columns, an account holds 1,000 tables and a million rows, and a page can query HubDB ten times. 2 Source 2 HubSpot Developers, “HubDB,” read October 31, 2026: 1,000 tables and 1 million rows per account; 10,000 rows and 250 columns per table; 10 calls to the hubdb_table_rows function per CMS page; queries return 1,000 rows by default. Ten thousand rows is a generous resource library. It’s a few years of requests for a firm with a busy portal, and less if every reply is a row.
| What a portal stores | Where it goes on HubSpot | The limit that applies |
|---|---|---|
| Lists the portal shows (departments, forms, documents) | HubDB | 10,000 rows a table; 10 lookups a page |
| Client requests and their status | Tickets or custom objects | API allowance shared with every integration |
| Replies and notes | CRM activities or HubDB rows | The same allowance, or HubDB’s row cap |
| Who can see what | Lists, access groups and the portal’s own code | Two access groups on Professional, 100 on Enterprise |
| Searches across records | CRM search | Five requests a second, per account |
HubSpot’s own developers draw the line plainly. A 2022 post on HubSpot’s developer blog says that for public data “HubDB is a great data source choice because you can create a public API,” and that “custom objects are particularly useful when it comes to private data and protecting your customers.” The public part isn’t hypothetical. A HubDB table is private by default, and one switch, “Allow public API access,” turns on “unauthenticated API calls to query the table’s data.” 3 Source 3 HubSpot Developer Blog, Hannah Seligson, “What’s the Difference Between HubDB and a Custom Object?,” November 3, 2022: for public data “HubDB is a great data source choice because you can create a public API”; “Custom objects are particularly useful when it comes to private data and protecting your customers.” HubSpot Knowledge Base, “Create and populate HubDB tables,” updated July 27, 2026: “By default, the table’s data can only be accessed in HubSpot through HubL or authenticated API calls”; the “Allow public API access” switch turns on “unauthenticated API calls to query the table’s data,” with the account ID in a portalId parameter. Client records shouldn’t be one toggle away from public.
Who and what can reach a portal’s data is the subject of Is HubSpot Private Content Secure? 12 Questions to Ask.
The CRM route: custom objects and an API you share
So the private records go into the CRM. Custom objects need an Enterprise subscription, and HubSpot limits how many you can create by tier. 4 Source 4 HubSpot Knowledge Base, “Create and edit custom objects,” updated October 20, 2026: available on Enterprise subscriptions; “depending on your subscription, there are limits on the number of custom objects and properties you may have.” Either way the portal reads and writes them through HubSpot’s API, and that’s where the second set of limits lives.
Each app gets 190 requests every 10 seconds. The daily allowance, 625,000 requests on Professional and a million on Enterprise, is “shared across all apps within the same HubSpot account.” Your portal draws on the same budget as your accounting sync, your scheduling tool and every other integration. Search is tighter still: five requests a second for the whole account, no more than 10,000 results for any query, and HubSpot notes that new or updated records “may take a few moments” to show up in search. 5 Source 5 HubSpot Developers, “API usage guidelines and limits,” read October 30, 2026: private apps on Professional and Enterprise get 190 requests per 10 seconds per app, and 625,000 (Professional) or 1,000,000 (Enterprise) requests a day, “shared across all apps within the same HubSpot account.” HubSpot Developers, CRM search guide, read October 31, 2026: “The search endpoints are rate limited to five requests per second per account”; “limited to 10,000 total results for any given query”; at most 200 objects per page; “It may take a few moments for newly created or updated CRM objects to appear in search results.”
Picture the start of a working day. If each dashboard view runs a search, thirty people opening the portal in the same few seconds are already past five a second. And the client who submitted a request a moment ago may not see it on their dashboard yet.
None of this makes the CRM a bad CRM. It makes it a shared, rate-limited service the portal has to queue for. The portal’s data model ends up being whatever the CRM allows, not what the business needs.
Who owns the portal’s records?
You do, on paper. In practice the record of how you serve each client lives inside a marketing platform, in that platform’s structures, and leaves under that platform’s export rules. HubSpot exports records object by object. 6 Source 6 HubSpot Knowledge Base, “Export your content and data,” updated September 25, 2026: exports are described tool by tool, including “records such as contacts, companies, deals, tickets, calls, custom objects, and more.” The shape that made them useful (which reply belongs to which request, who approved it, what the dashboard showed a client on a given day) is something you rebuild on the other side. We’ve written about why owning your data in HubSpot is more complicated than it sounds.
For regulated firms the question is sharper. If clients and staff correspond through the portal, that correspondence may have to be kept for years and produced on request. Doing that well means the firm controls where the records live, how long they’re kept and how they’re searched. On HubSpot, those decisions are shared with the vendor.
The portal’s data model ends up being whatever the CRM allows, not what the business needs.
What a portal database you own gives you
A database built for the portal holds records the way the business works: a request with its replies, attachments, approvals and history in one place, modelled once and queried any way you like. Your reports run against it directly, at whatever pace you need, with no allowance to share. Retention follows your compliance policy. If you change vendors, the data doesn’t move, because it was never theirs.
HubSpot keeps its job. The portal sends the CRM what it needs (contacts, activity, the status of each request) so sales and marketing see the full relationship. The CRM is fed from the record of service rather than standing in for it.
That’s the outcome worth paying for: client history you own outright, ready for the reporting and the AI work every firm is now planning, because it’s your data layer, not the vendor’s. The compute side of the same problem is in HubSpot Serverless Function Limits for Client Portals (2026). The full picture starts with Can You Build a Customer Portal on HubSpot?, and the choice of home is in Custom Client Portal or HubSpot? 5 Options Compared.
The research is free. So is the diagnosis. 60 seconds →