Every event platform I've ever opened is a CRM wearing a lanyard.
Contacts. Companies. Deals. Rows in tables, tables in modules, modules in a dashboard. The vocabulary changes — "attendees" instead of leads, "exhibitors" instead of accounts — but the architecture underneath is the same one built to track sales pipelines in the nineties. And that architecture is quietly the reason so much event software feels like it's fighting the event instead of running it.
We made one decision early at mytradeshow.ai that shaped everything after it: the database isn't a list. It's a graph. Here's what that means, why it matters more than any feature we could have shipped, and why I think the whole industry needs to stop thinking like Salesforce and start thinking like LinkedIn.
A tradeshow is not a list of records
Ask a CRM what it knows about an attendee and you get a card: Marie, procurement director, this email, that company, attended 2025, badge scanned twice.
Now ask what a tradeshow actually is. For three days, ten thousand people compress a year of an industry's relationships into one building. Marie doesn't exist at your show as a row — she exists as a knot of connections. She works at a company that sources from two categories on your floor. She met four suppliers at the last edition, followed up with two, went quiet on one. Her colleague walked the same aisles with a different brief. The supplier she declined is exhibiting again, three booths down from their competitor she's never spoken to.
None of that fits in a card. All of it is the show. A tradeshow is the densest social network on earth while it runs — and we've been storing it in software built for filing.
The LinkedIn lesson
LinkedIn's founding insight wasn't a better address book. Address books existed; they were called Rolodexes and they worked fine. The insight was that the value isn't in the people — it's in the edges between them. Who knows whom. Who worked where, with whom, when. Once you store the connections as first-class data, entirely new questions become answerable: who can introduce me to this buyer? Who else moved from that industry to this one? Who do I know at second degree that I should know at first?
LinkedIn didn't beat the Rolodex by making a better Rolodex. It changed what the data was.
That's the exact move event software hasn't made. A CRM stores your show. A graph understands it.
What we actually built: a graph database for events
Concretely: at the heart of mytradeshow.ai is a property graph — nodes and edges, not tables and joins.
The nodes are the things your show is made of: people, companies, shows, editions, booths, meetings, sessions, product categories, sourcing briefs.
The edges are the relationships — and this is where it gets interesting, because every edge is typed and time-stamped. Marie attended edition 2025. Acme exhibited at booth B42. Marie met that supplier — with an outcome attached. She requested this meeting, declined that one, works at Acme, which sources from this category. Dana, our enrichment agent, attaches firmographics to the company node — once — and every show that company ever touches benefits from it.
Two consequences fall out of this structure that no amount of feature-building on a relational base can replicate.
First: memory is native. In a CRM, every edition is a new spreadsheet — the reason I wrote that your show forgets everything every year. In a graph, an edition is just a new layer of time-stamped edges on nodes that persist. The 2026 edition doesn't start from zero; it starts from everything 2025 learned, structurally, without a migration project.
Second: matchmaking becomes path-finding, not filtering. "Show me attendees whose interest tags overlap" is a database filter — that's what most matchmaking is, and it's why it plateaus. "Who should Marie meet?" in a graph is a traversal: start at Marie, walk through her company, its sourcing categories, the suppliers in those categories she hasn't met, weighted by what happened when people like her — same role, same category edges — met them at previous editions. Second-degree logic. The recommendation your best salesperson makes from memory and instinct, computed across the whole floor.
That's also what our agents actually do all day. Connor doesn't scan a list; he walks the graph. When a meeting falls through, the next-best pair isn't a re-query — it's the next-shortest valuable path.
And a third consequence, quieter but maybe the biggest: questions become cheap. Every organizer has a list of things they'd love to know and have stopped asking, because in a CRM each one is a week of exports and pivot tables. Which exhibitors met buyers from the markets they told us they wanted? Which attendees came two editions running but booked zero meetings this time — and who should have noticed? Which category on the floor is quietly becoming the reason people come? In a graph these aren't projects. They're queries — a walk from one set of nodes to another. When a question costs seconds instead of a week, you ask a hundred more of them, and the show starts being run on answers instead of instinct. That, more than any single feature, is what a data model buys you: a different relationship with your own curiosity.
What I won't claim
Three honest nuances, because architecture posts are usually propaganda.
A graph full of garbage is worse than a list full of garbage. Wrong edges produce confidently wrong recommendations. The unglamorous majority of our data work is identity resolution — knowing that "ACME Corp", "Acme SAS" and the Acme that exhibited under a distributor's name are one node, not three. If you're an organizer evaluating anyone's "knowledge graph" claims, ask about deduplication before you ask about AI. The graph is only as good as its nodes are true.
Relational databases aren't the enemy. Registration, invoicing, badge printing — transactional work belongs in transactional stores, and parts of our stack are exactly that. The graph is for the relationship layer, because that's where the questions live. Nobody should rewrite their ticketing in graph queries to feel modern.
Edges are the most sensitive data you hold. Who met whom, who declined whom — that's more private than any profile field. Graph thinking forces you to take isolation and consent seriously from the schema up: organizer boundaries, attendee-controlled visibility, GDPR by structure rather than by policy document. If a vendor tells you about their graph but not about its permissions model, keep asking.
Why this reshapes the industry, not just our product
Here's the uncomfortable implication for event tech as a category: most of the ceiling organizers hit isn't a feature gap. It's a data-model gap. You can't bolt second-degree recommendations onto a contacts table. You can't make a show remember by adding a "previous edition" column. The platforms that store events as lists will keep shipping better filters — and filters aren't understanding.
And there's a network property that lists can never have: every show that runs on a shared graph makes the graph denser, and a denser graph makes every other show's matching sharper. That's the same compounding loop that made LinkedIn unbeatable — each new member made the network more valuable for every existing member. Events have been the one industry where the network resets to zero every year, per show, per vendor. It doesn't have to.
The tradeshow industry sells connection. It's time its software was built out of connections too.
Disagree with the architecture? I'd genuinely like to hear it — this is the kind of argument the industry should be having in public. Write in.
Related reading linked in studio (2).