CRM Database Examples: 4 Schemas + How to Design Your Own (2026)

A CRM database is the relational backbone that ties every customer interaction together - leads, contacts, deals, support tickets and the people on your team who own them. Get the schema right and your CRM scales with you. Get it wrong and you end up paying per-user fees for a tool that still doesn't fit how you actually work.

This guide shows you four real CRM database schemas - the canonical 6-entity model plus three industry-specific variants (B2B sales SaaS, e-commerce, real estate) - and a 7-step plan to design your own. Every diagram is a real schema you can copy, adapt, or hand to an AI tool like Fuzen's AI CRM builder to generate live tables, views and workflows from a prompt.

What is a CRM database?

A CRM (Customer Relationship Management) database stores all your customer information in one place - contacts, accounts, deals, communication logs, support tickets, and the activities that connect them. It is the central data layer that sales, marketing and support teams read and write to throughout every workflow.

The shape of a good CRM database is the same across industries - six core entities tied together with foreign keys - but the fields, relationships and vertical-specific tables are where the real customisation lives. That's the difference between a SaaS CRM (one schema for everyone) and a custom CRM (a schema designed around your actual sales motion).

The 6 entities every CRM database needs

Every CRM you've ever used - Salesforce, HubSpot, Zoho, Pipedrive - is built on these six relational tables. The names sometimes change (Account → Company, Deal → Opportunity), but the shape doesn't.

Once you have these six entities and their foreign keys in place, everything else - pipeline views, dashboards, role-based access, automation triggers - is a query or a workflow on top.

3 CRM database examples by industry

Below are three schemas that each start from the canonical model above, then add the entities and fields that only matter to that vertical. Use them as a blueprint, not a rulebook - the goal of a custom CRM is to remove fields you don't need and add the ones you do.

1. B2B Sales SaaS - Subscription + Pipeline_Stage

The B2B SaaS variant adds two entities that matter for recurring revenue:

• Subscription stores the active contract - plan, seat count, MRR, ARR and renewal date. Linked to Account, not Contact, because contracts live with the company.
• Pipeline_Stage is a configurable lookup table for your sales stages (New → Qualified → Proposal → Won → Lost) with order and probability. Storing stages in their own table lets you reorder, rename or add stages without a schema migration.

The Opportunity record (renamed Deal) carries MRR and ARR directly so you can roll up forecasts without joins. Activity tracks every demo, follow-up email and call with an outcome field that feeds your conversion-rate reporting. Fields like lead_score (AI) on Lead are where AI scoring plugs in - a workflow updates that number every time new data lands.

2. E-commerce - Order replaces Deal, plus Cart and Product

E-commerce CRMs swap a few entities to fit the order-driven motion:

• Order replaces Deal - a customer placed a transaction with a status (pending / paid / shipped / delivered / refunded).
• Order_Item is the line-item junction table between Order and Product so a single order can contain multiple products with quantity and unit price snapshots.
• Cart tracks active and abandoned shopping sessions so you can trigger abandonment workflows.
• Address is broken out separately so a customer can store multiple shipping and billing addresses.

Lifetime value sits on Customer as a precomputed field - cheap to read, recalculated periodically by a workflow rather than on every query. Activity is scoped to the customer with a campaign_id so you can attribute revenue to your email and SMS efforts.

3. Real estate - Property is central; Listing, Showing and Offer wrap it

Real estate is the one vertical where the customer isn't the centre of the schema - the Property is. Buyers, sellers, listings and offers all revolve around it.

• Property stores the unit - address, type, bedrooms, list price, MLS id. Same physical property might be listed multiple times over its lifetime.
• Listing represents one active for-sale (or for-rent) period with a status and expiry. A single Property can have several Listing rows across history.
• Showing is the appointment record - which Contact viewed which Property, when, and the feedback after.
• Offer stores the financial proposal from a buyer with status (made / countered / accepted / rejected).
• Agent is the User in real estate language, with extras like license number and commission split.

The Lead record on the left tracks initial interest (buy / sell / rent) before the person has been qualified into a Contact role.

How to design a CRM database in 7 steps

If you're building a CRM from scratch - whether you're sketching it in a low-cost tool, prompting an AI builder, or briefing a developer - here's the order to do it in.

1. List your entities first, fields second. Start with the 6 canonical entities (Lead, Contact, Account, Deal, Activity, User). Add vertical-specific entities only when you've identified a real workflow they support (e.g. Property for real estate, Subscription for SaaS). Resist the urge to add entities for things that are really just fields.
2. Define primary keys explicitly. Every entity gets an {entity}_id primary key. Use UUIDs if you'll ever sync across systems; auto-increment integers are fine for single-tenant CRMs.
3. Map foreign keys before fields. A Contact belongs to an Account → contact.account_id. A Deal links to both → deal.contact_id + deal.account_id. Draw the relationship arrows on paper or in a tool like dbdiagram.io before you start enumerating columns.
4. Add the must-have fields per entity. Use the tables in the examples above as a starting point. Trim ruthlessly - every field you add is a field a sales rep has to fill in, ignore, or scroll past.
5. Decide on Activity's polymorphic relationship. Activity attaches to multiple parent entities (Lead, Contact, Account, Deal). You can either use a polymorphic related_id + related_type pair (flexible, harder to enforce referential integrity) or a separate join table per parent (cleaner, more tables). Both work - pick one and be consistent.
6. Plan for soft delete and audit. Add created_at, updated_at and deleted_at to every entity from day one. CRM data is rarely truly deleted - you want the audit trail.
7. Test with sample data before adding workflows. Load 50-100 sample records per entity, run the queries your reports will need, and confirm joins return what you expect. Adding pipeline views, automations and dashboards on a broken schema is expensive to unwind.

Key considerations in CRM database design

Beyond the entity structure, these are the design decisions that separate a CRM database that scales from one you'll rebuild in 18 months.

• Identify the data you actually use. Every additional field is a sales rep deciding whether to fill it in. Audit your spreadsheets and current tools: what fields do reps consistently use? Start there. Fields you might want later can be added later.
• Separate operational from analytical fields. Operational fields (status, stage, owner) get written to constantly. Analytical fields (lifetime_value, lead_score) are computed periodically. Treat them differently in your schema and your indexes.
• Plan for multi-currency, multi-language, multi-region from day one. Add currency_code to anything with a money amount, locale to user records, and country_code to addresses. Backfilling later is painful.
• Decide on role-based access early. Will reps see only their own deals or all deals? Will managers see their team's data? Build the User → Team relationship and access rules into the schema before you build views on top.
• Use indexes deliberately. Index foreign keys, frequently filtered fields (status, stage, owner_id) and any field used in a sort. Skip indexing free-text fields unless you need full-text search.
• Plan integrations as part of the schema. Webhook destination URLs, external_id columns for sync, and integration-specific tables (e.g. mailchimp_campaign_id) belong in the schema, not as afterthoughts.

Building your CRM database with Fuzen

If you've made it this far, you're seriously considering building a custom CRM rather than renting one. The economics work out: a Fuzen custom CRM costs roughly six months of equivalent SaaS subscription as a one-time investment ($200-$500 for a small build, scaling up with complexity), and you own the schema, the data, and the workflows.

Fuzen does the heavy lifting in two ways depending on how hands-on you want to be:

• Done-for-you build - you describe your sales motion on a scoping call, our team builds the schema, pipeline views, dashboards and integrations, and ships you a working CRM in 3-4 weeks. You pay 10% upfront, 90% on approval. See how custom CRM delivery works.
• AI Builder - you describe the CRM you want in plain English, Fuzen's AI generates the database, the UI and the workflows in real time. You iterate by prompting changes. Best for technical teams who want full control. Try the AI CRM builder.

Either path, you start from one of the schemas above (or a vertical-specific CRM template), customise the fields and workflows for your sales motion, and ship. No per-user fees, no recurring SaaS subscription, no vendor lock-in - the code and data are yours from day one.

Frequently asked questions

What is an internal CRM?

An internal CRM is a custom customer relationship management system built and managed in-house (or by a delivery partner) rather than purchased as off-the-shelf SaaS. It centralises customer data and is fully tailored to the organisation's specific workflows. Internal CRMs offer more customisation, no per-user fees, and full code + data ownership, in exchange for higher upfront cost and longer initial setup vs subscription tools.

What are the 6 entities every CRM database needs?

Lead, Contact, Account, Deal, Activity and User. These six relational tables make up the canonical CRM schema regardless of vendor. Different industries add vertical-specific entities on top - Property in real estate, Subscription in SaaS, Order in e-commerce - but the six core entities are invariant.

How much does it cost to build a custom CRM database?

Traditional agency or in-house development of a custom CRM costs $30,000-$120,000+ and takes 3-9 months depending on scope. Using an AI-assisted no-code platform like Fuzen, an equivalent custom CRM costs $200-$25,000 one-time (plus $99/yr hosting) depending on complexity - roughly six months of equivalent SaaS subscription, paid once.

Is a CRM database the same as a customer database?

A customer database stores customer records (name, email, address, history). A CRM database stores the customer relationship - not just who they are but where they are in your funnel, who on your team owns them, what activities they've had, and what deals they're in. The CRM database includes a customer database as one part of a richer relational model.

Can I build a CRM database in Excel or Google Sheets?

For under 50 contacts and one user, yes - a flat sheet with columns for name, company, stage and owner is a real CRM. Past that, the lack of relational integrity (a contact in a deal that doesn't exist, a stage that doesn't match anything) creates more cleanup time than the savings justify. Most teams outgrow spreadsheet CRMs within 6-12 months. See how to migrate from spreadsheet to custom CRM.

What's the difference between a CRM database and a CRM system?

The CRM database is the data layer - tables, relationships, fields. The CRM system is the database plus the user interface, workflows, automation, integrations and reporting on top. You design the database first because every UI screen and every automation reads or writes to it.

Conclusion

A well-designed CRM database is six core entities tied with foreign keys - Lead, Contact, Account, Deal, Activity, User - plus the vertical-specific entities your sales motion actually needs. The four schemas in this guide give you a working blueprint for the most common motions; the 7-step design plan shows you how to adapt them for yours.

When you're ready to build, the choice is whether to do it yourself in code, use an AI builder, brief a development team, or have it built and delivered for you. Get a scoped quote for a custom CRM built and delivered, or try the AI builder yourself.