Expanding Mautic’s Data Model: Introducing Custom Tables

Ideas and Feature Requests
1

Hello,

Mautic has long empowered marketers with flexible data management through custom fields. These fields allow users to extend contact profiles with additional attributes tailored to their business needs. However, as use cases grow more advanced, the current model begins to show its limits—particularly when working with structured, repeatable, or relational data.

It’s time to consider the next evolution: custom tables.

The Limitation of Custom Fields

Custom fields are excellent for simple, flat data—text values, numbers, dates, and boolean flags. But modern marketing operations increasingly rely on more sophisticated data structures, such as:

  • Repeatable datasets (e.g., multiple purchases, interactions, or subscriptions)

  • Relational data between entities

  • Complex schemas coming from external systems

To work around these limitations, users often:

  • Overload contact records with duplicated or indexed fields, or

  • Offload structured data into external systems

Both approaches introduce friction, complexity, fragmentation and can hit database hard limits.

Introducing Custom Tables

Now imagine a system where users can create custom tables within Mautic, just as easily as adding a custom field—but with far greater flexibility.

This feature would allow users to define structured, relational datasets directly inside Mautic, linked to core entities like contacts, companies, or campaigns.

From Fields to Fully Custom Schemas

With custom tables, users wouldn’t just be adding data—they would be designing data models.

Users could create ever more complex schemas within Mautic, limited only by their imagination. What previously required a developer, external database, or middleware could now be handled natively within the platform.

This opens the door to:

  • Multi-layered relational data structures

  • Nested and repeatable records

  • Schema designs that mirror real business processes

In effect, Mautic would evolve from a system that stores marketing data into one that can model it with precision.

This feature would allow complex schemas—previously only achievable through custom development—to be built, managed, and leveraged directly within Mautic’s interface.

Key Capabilities

  • Custom Schema Definition
    Define tables, columns, data types, and relationships through an intuitive UI.

  • One-to-Many & Many-to-One Relationships
    Associate multiple records (e.g., orders, events, tickets) with a single contact or company.

  • Advanced Segmentation
    Build segments using conditions across related tables (e.g., “contacts with 3+ purchases in the last 30 days”).

  • Normalized Data Storage
    Eliminate cluttered contact records and improve data integrity.

  • API-First Integration
    Allow external systems to push structured, relational data directly into Mautic.

Real-World Use Cases

  • E-commerce
    Maintain full order histories, product relationships, and transaction data.

  • Event Management
    Track registrations, attendance, and engagement across multiple events per contact.

  • SaaS Platforms
    Store subscriptions, feature usage, and lifecycle data.

  • Custom Business Logic
    Model domain-specific processes such as applications, claims, or onboarding steps.

User Experience Considerations

To ensure adoption, the experience should remain as intuitive as custom fields:

  • A dedicated “Custom Tables” section in settings

  • Guided schema creation with validation and previews

  • Visual relationship mapping between entities

  • Query builders for segmentation and campaign logic

The goal is power without sacrificing usability.

Performance & Architecture

Supporting custom tables would require thoughtful design:

  • Optimized joins and indexing strategies

  • Efficient query execution for segmentation

  • Caching layers for performance at scale

  • Backward compatibility with existing field-based systems

While technically complex, this investment would significantly expand Mautic’s capabilities.

Why This Matters

Marketing today is driven by data depth, not just data points. The ability to model relationships, track histories, and reflect real-world complexity is essential for meaningful automation.

By enabling custom tables, Mautic could empower users to:

  • Build richer, more accurate customer profiles

  • Reduce reliance on external systems

  • Unlock advanced personalization and automation

  • Bridge the gap between marketing tools and full customer data platforms

Final Thoughts

Custom fields were a powerful foundation. Custom tables are the natural next step.

By allowing users to define and manage complex schemas directly within Mautic, the platform can evolve into a truly flexible, developer-friendly, and future-ready system—without losing its accessibility.

This isn’t just a feature upgrade. It’s a shift toward making Mautic a platform where any data model a developer can imagine can be brought to life—no compromises required.

Thanks

2

Hello,

Why Custom Tables Would Solve Real Mautic Limitations

In my previous post, I explored the idea of introducing custom tables into Mautic as a natural evolution beyond custom fields. In this follow-up, I want to focus on something more practical: the real problems this would solve.

This isn’t just a “nice to have” feature—it directly addresses limitations that many users, including myself, have already encountered.

The Hidden Ceiling of Custom Fields

From my perspective, one of the biggest issues with the current system is what happens when you scale.

Adding large numbers of custom fields to the contact table may seem fine at first—but eventually, you run into hard database limits on some databases engines.

  • Column limits: Most databases impose a maximum number of columns per table.

  • Index limits: The number of indexes is also finite, and Mautic relies heavily on indexing for performance.

As more fields are added, performance degrades, schema management becomes harder, and eventually, you simply can’t add more fields.

This creates an artificial ceiling on what should otherwise be a flexible system.

Custom Tables as a Structural Solution

Custom tables would fundamentally solve this problem by moving away from a single, overloaded contact table.

Instead of forcing everything into one structure, we could:

  • Distribute data across multiple purpose-built tables

  • Define relationships rather than duplicating fields

  • Keep schemas clean, efficient, and scalable

This isn’t just about flexibility—it’s about long-term sustainability of the data model.

Moving Beyond Custom Object Plugins

There have been attempts to address this problem through plugins that have yet to be released, such as custom object solutions. While helpful, they inevitably come with limitations:

  • Restricted flexibility compared to native features

  • Dependency on plugin maintenance and compatibility

  • Constraints imposed by plugin architecture

Rather than relying on workarounds, it would be far more powerful to make this a core capability.

No need for a custom object plugin—just allow users to create custom tables and define relationships directly within Mautic.

Build Your Own Schema

One of the most compelling advantages of this approach is freedom.

Users could design their own schema to match their exact business needs:

  • Simple extensions for lightweight use cases

  • Complex relational models for advanced implementations

  • Structures that align with external systems and data pipelines

In short, we move from “working around Mautic’s structure” to defining our own.

Table Prefixing & Clean Separation

In my own setup, I already use table prefixes to organize and manage data more effectively. Extending this concept to custom tables would be incredibly useful.

Custom tables could:

  • Use a separate prefix (or multiple prefixes)

  • Be clearly distinguished from core Mautic tables

  • Remain isolated for easier maintenance, backup, and migration

This separation would also reduce risk, making it easier to manage upgrades and troubleshoot issues without interfering with core functionality.

A More Scalable Future for Mautic

Ultimately, this comes down to scalability.

Right now, pushing Mautic beyond certain limits requires compromises—either technical workarounds or external systems. Custom tables would remove that friction and allow the platform to scale more naturally with real-world use cases.

Final Thought

From my perspective, custom tables wouldn’t just enhance Mautic—they would resolve fundamental architectural constraints that users are already hitting today.

Instead of stretching the current system to its limits, this approach gives us a way to expand it cleanly, logically, and sustainably.

And perhaps most importantly, it puts control back where it belongs: in the hands of the user.

Thanks

3

Why not turn Mautic Forms into ‘custom tables’ ?

4

Hi, how would this solve OPs issue? As far as I understood, OP would like an enhanced database model for his use case.

In general, there is a lack in flexibility in I think all marketing automation software and imo the problem with all marketing automation software I know is that it’s trying to be something it shouldn’t. And almost always it is piggybacking a CRM on top of a halfway finished automation layer. What people tend to forget is the difference in nature between a CRM and Marketing Automation Software. A CRM is always state driven while Automation is event driven. And state can be found everywhere. For some it lies in a spreadsheet, for others in enterprise software. But Marketing Automation only cares about a subset of the state and eventually it only cares about some state changing events that impact marketing. While I see use cases for OPs suggestion, e.g. holding information about all webinars a contact plans to visit, we should ensure that changes actually improve automation rather than just dumping data into Mautic.

5

Hello joeyk,

Yes, using forms to effectively create custom tables is an intriguing idea, and it’s something I plan to explore. That said, I see it as a short-term workaround at best—but I do appreciate the suggestion and and effort.

Mautic as a concept is wonderful. However, from a database perspective, its schema is quite limiting due to its largely flat design. I won’t revisit all the points I’ve already raised, but this constraint becomes increasingly apparent as implementations grow in complexity.

At present, I don’t have the Symfony expertise required to implement custom tables within Mautic myself. That said, for experienced developers working within the platform, this would likely be a relatively straightforward enhancement—one that could benefit the entire community. I’m also not suggesting this needs to be a paid feature; it feels like a natural evolution of the core platform.

In the short term, I can extend Mautic’s schema externally using SQL and other programming approaches. This allows me to build a more efficient and scalable data structure without interfering with Mautic’s core functionality or upgrade path.

As my experience with Symfony improves, I would certainly consider contributing toward implementing custom tables directly within Mautic in the future. User can then choose to use Mautic as is or add custom tables. It becomes end user choice and not limited by Mautic.

The goal of raising this feature request is simply to open the discussion. Ideally, it resonates with a developer who sees the value and is in a position to implement it.

Until then, extending the schema externally provides a workable interim solution—one that maintains compatibility while addressing current limitations.

I hope the developer community sees and acknowledges the power and freedom this feature would give to end users, and takes a serious look at implementing it—perhaps in small, incremental steps until it is fully realised.

Thanks for taking the time to read through the idea—I appreciate it’s quite a detailed one.

6

Hello dband,

To give a practical example of the limitation:

We currently sell at least ten different products, each with its own subscription start and end date. In the future, we’re likely to expand this to twenty or more products.

From a marketing perspective, I want to:

  • Send emails based on the specific product a contact has purchased

  • Trigger campaigns when a subscription is nearing expiry

  • Automatically promote more advanced versions of the same product during an active subscription

This requires a structured, repeatable dataset—essentially a list of subscriptions per contact, each with its own attributes (product type, start date, end date, status, etc.).

This is not something that can be cleanly or sustainably implemented using custom fields on the contact record.

Attempting to do so would mean:

  • Creating multiple fields per product (e.g., product1_start, product1_end, product2_start, etc.)

  • Continuously adding more fields as new products are introduced

  • Rapidly approaching database column and index limits

  • Experiencing degraded performance due to excessive indexing and table size

In short, the flat structure forces a solution that does not scale.

What this scenario really requires is a separate, related table of subscriptions, where each contact can have multiple associated records. This would allow:

  • Unlimited products without schema bloat

  • Clean querying for segmentation and automation

  • Efficient indexing and better performance

  • A far more natural representation of real-world data

There are already signs within the community that these limits are being reached. For example, I’ve seen a user exploring a move to PostgreSQL after hitting hard database limits in MariaDB—largely due to the constraints imposed by the flat schema.

However, the underlying issue isn’t the database technology itself. Switching databases may delay the problem, but it doesn’t resolve it. The real solution is to allow the schema to be extended properly, so that these hard limits are not encountered regardless of the database being used.

This approach aligns with well-established database design principles—normalisation, relational modelling, and separation of concerns—which are standard topics in university database courses and widely covered in software engineering literature.

This example highlights why custom tables are not just a “nice feature,” but a necessary step toward making Mautic scalable for more advanced and realistic use cases.

Thanks

7

Hello dband,,

Here is another example:

Tags Stored as JSON: A Structural Limitation

Another area where Mautic’s data model shows its limitations is in how tags are stored.

Currently, tags are held in a JSON structure rather than a properly normalised relational model. While this offers some flexibility, it creates real issues as data grows.

  • Poor query performance – JSON fields are harder to index, leading to slower segmentation and filtering

  • Limited scalability – performance degrades as the dataset increases

  • Lack of structure – difficult to extend tags with additional attributes or relationships

  • Breaks standard design principles – bypasses normalisation and relational integrity

Tags are a core part of segmentation and automation, so these limitations have a direct impact on real-world usage.

A Better Approach

A relational structure (e.g., tags and contact_tags tables) would allow:

  • Fast indexed queries

  • Clean many-to-many relationships

  • Greater flexibility and extensibility

More importantly, the introduction of custom tables in Mautic would naturally enable this approach.

Users could define their own relational tag tables, tailored to their needs, resolving many of these limitations without being constrained by the current JSON-based implementation.

Final Thought

This is another example where moving toward a more relational, extensible schema—supported by custom tables—would significantly improve performance, scalability, and flexibility within Mautic.

For those who want simplicity they don’t have to use custom tables. For those sunning at scale custom tables gives them endless options to expand the schema and make it more efficient in any way they choose.

Set Mautic free and allow end users to use the enormous power of relational databases by implementing custom tables

Thanks

8

Hi, I partially agree :slight_smile: one would have to decide what to index and what not, which would be a problem on its own.

Also, your use case to detect subscription end of life does not only need an enhanced data model but also segment rework.

I don’t like extensive data models because they are not solving any problems in a marketing system. At least, if it’s not used as a CRM. Such a system should rely on trigger points and not recalculating segment state every few minutes based on CRM fields. That’s why we started using external triggers to cluster contacts and use Mautic to focus on campaign delivery.

I am with you on improving performance of tags though, if needed. I never looked at how they are implemented. These are the backbone of Mautic and we make heavy use of them.

9

Hello dband,

I don’t want to repeat what I’ve already said, but to summarise:

Custom fields in Mautic can only be added to contact and company records.

The number of custom fields you can add to a given table is limited. In MariaDB, it’s been suggested this is around 50–60 fields. There are claims this limit could be higher with alternative databases like Progress SQL, but the exact limits are unclear.

More importantly, expanding contact and company tables to that extent introduces significant performance issues. As tables become wider, you quickly lose the ability to add indexes effectively, which leads to serious database performance degradation.

Wide table designs are generally considered poor practice in modern database architecture and are typically avoided. However, Mautic continues to rely on this schema model.

If Mautic supported custom tables and allowed custom fields within those tables, many of these limitations could be avoided through better schema design. In that scenario, performance would scale more naturally with server resources rather than being constrained by the schema itself.

As it stands, the Mautic UI does not support building complex segment rules. I’ve suggested improvements in the past, but these haven’t gained much traction. That said, there is a low-cost plugin available which allows you to run SQL queries against Mautic (and custom) tables and return contact_id values for segmentation.

In practice, this means I can already create custom tables directly in SQL and use that plugin to build highly complex segments based on any query I design. So the functionality I need is achievable today outside of Mautic.

I had hoped to encourage the developers to improve the segment rule builder and support custom tables natively. However, at this point, it feels unlikely this will happen—if there were intent to address the underlying database design, it likely would have been done long ago.

Ultimately, the constraint is Mautic’s architecture, which remains under the control of its developers, rather than any limitation of the database technology or server hardware.

Thanks

10

I understand. Ultimately you have to agree though, that you turn this system into a full CRM with Marketing Automation capabilities.

At this point, you have Hubspot (light). I would like to move the other direction; ditch most of the custom fields and just keep what’s necessary to identify a contact and it’s marketing relevant stage. Everything else is triggered externally.

There are good CMS systems like directus.io (not affiliated) which could be used as a data layer. It took them years to build a stable solution for custom data models.

Apart from the data model issue I would also question the approach of rebuilding complex segments in intervals. Especially larger systems (which you are referring to) should rather recalculate contact state on change and thus decide if a contact drops out of a segment or not.

Talking about data, Mautic feels bulky. And I believe adding a more extensive data mode wouldn’t simplify anything. It will solve some problems, I agree, but it would hurt maintainability. At this point, I feel, that we should remove as much as possible from Mautic core and break leftover modules into plugins via contracts to enable automation.

11

The need for custom tables is not necessarily meant to make it a full CRM, @dband .

There are a couple of use cases directly related to marketing automation, which currently can’t really be implemented without custom tables. Therefore there is / was the custom objects plugin ( GitHub - acquia/mc-cs-plugin-custom-objects: Mautic plugin adding Custom Objects feature · GitHub ).

Think of different contracts a contact holds: They have different parameters - start, end, contract type. If you like to implement a campaign related to that - currently this would only work for one contract.

As I understand the proposal, the custom tables plugin is a bit more generic in potential use cases? In order to support campaigns, this would also have some requirements in terms of campaign actions and field_tokens…

12

@dirk_s Yes, that’s indeed a restriction and like you said we would need to change segments and campaigns as well.

Again, Mautic is a Marketing Automation Software. And every change we make should benefit automation. Thus, I personally, would not implement a generic data model like @andrew_c3 is suggesting without having a plan to rework segments and campaigns as well. And that’s pretty much Mautics whole automation functionality.
A generic data model is not trivial to implement. While it’s easy to create tables for your own use case straight on the database level and then hack your way through with SQL, adding this functionality via UI is not. Would you let the user create database indices? How to handle deletes?

Relational data models are not the holy grail. I want this topic to be thought through. There are valid reasons why you would want to flatten your data. Especially when you are trying to develop a system that fits for many use cases.

As of right now, it is true that we need third party software to leverage the shortcomings of plain Mautic. Especially, when we don’t have the option of touching the database with SQL statements.

Lastly, I do have these problems as well. So, it’s not like I am farting empty words. Where I work, we offer of Webinars and there is no way to send a freaking reminder out of Mautic because a contact can be in a campaign only once at a time, because relative dates in segments don’t work AND because a user can attend a Webinar multiple times but there is no damnit way to declare either explicit nor implicit relations between a webinar and a contact.

13

Hello dband,

I think there’s some confusion here about how relational databases — and Mautic — actually work.

Custom tables would simply allow the creation of additional tables in the database via the Mautic UI. That’s a convenience feature, not a transformation of Mautic into a CRM. A CRM is defined by its application logic (pipelines, deals, relationships, workflows), not by whether you can create tables.

If custom tables aren’t something you personally need, you can simply choose not to use them. That said, dismissing the feature outright overlooks the fact that more advanced users and developers may rely on that flexibility to build more sophisticated data models.

The idea that Mautic should effectively “hit a hard limit” after 50–60 custom fields is not realistic from a database design perspective. No database designer would intentionally impose such a restrictive ceiling on extensibility. That kind of limitation constrains legitimate use cases and prevents more advanced data modeling.

What this position effectively suggests is that Mautic shouldn’t evolve because increased flexibility might allow others to do more advanced marketing. Holding the platform back to fit a constrained schema benefits no one.

It’s also worth noting that everything being discussed here is already possible at the database level using SQL. Additional tables, fields, indexes, and relationships can already be created directly, giving complete freedom to design whatever data model is required. Exposing this capability through the UI doesn’t introduce something new — it simply makes it more accessible and user-friendly.

So the real question is: what exactly is the concern with making that flexibility easier for those who need it?

14

First of, I am not opposed to change. Your solution is an architectural overhaul of Mautic. Such a decision must be thought through. That’s all I am saying.

Second, creating tables on a database level via SQL is completely different from schema modification via UI. It’s not just “exposing functionality over the UI”. Adding custom fields is a very limited subset of sql operations compared to what would be necessary to make custom relational models work.

Third, the user should not have to learn SQL or understand how relational databases work. Mautic is not a tool for devs, it’s a tool for marketers. Exposing raw database APIs is not how it should be done.

Fourth, this is not the only critical issue that must be addressed in Mautic but at least there is a workaround. Hello GDPR.

Lastly, there is always a use case that is not covered. But if you would want your solution to work, I guess it would be best to start with a minimal relation model that only covers 1:n relations between a contact and another entity. Then, we would still have to figure out how to integrate these relations into segments and campaigns WITHOUT SQL hacks…

15

Hello dband,

I can implement custom tables at the database level, as I have over 20 years of experience working with databases. If anyone would like advice or consultancy on extending Mautic beyond its current schema limitations, feel free to contact me privately.

Thank you for your recent post, which now highlights and supports the broader need for custom tables within the Mautic UI to better serve marketers. I appreciate your engagement on this feature request and change of mind.

I also wanted to raise a concern:

I previously advocated for the concept of Custom Objects in a feature request, and at the time the project lead mentioned that a developer was working on it with a view to potential release in M7. I recently revisited the thread to ask for an update, but I noticed that comments referencing ongoing development and inclusion in core appear to have been removed. This is quite concerning and I would appreciate clarification on the status.

If there are any remaining objections to Custom Tables, I’m happy to continue the discussion and better understand the reasoning behind them.

Thank you.

16

Hello,

Extending Mautic with Custom Tables — A Practical Approach

Implementing custom tables directly within Mautic can require significant development effort. This typically involves working with PHP and Symfony to modify the front end—specifically forms and the menu system. While making these changes in the core can simplify some aspects, doing so via a plugin is often more complex and limiting.

The free custom object plugin mentioned earlier appears to support Mautic 4 (M4) and possibly M5, but not M6 or M7. From what I can tell, this limitation is largely due to the complexity of front-end changes required. One of Mautic’s experienced developers is contributing to the project. The plugin was first released in 2022, and most marketers currently using it seem to remain on M4. There is no sign of M7 compatibility any time soon. Check out the project GitHub.

Expertise Required for This Approach

  • No PHP or Symfony coding required

  • Basic knowledge of SQL or database administration

  • Option to learn Symfony and deeper development later when time allows

My Solution

Instead of relying on plugins or core modifications, I recommend a more flexible, database-driven approach:

  1. Use an open-source database administration tool to create any custom tables or fields you need.

  2. Connect an open-source GUI form builder directly to the Mautic database to:

    • Create forms

    • Populate custom tables and fields in real time

  3. Use an affordable SQL plugin to build segments and campaign rules based on both Mautic data and your custom tables

  4. Continue using Mautic as normal for campaigns and automation.

Priority

  • Start building advanced segments and campaign logic immediately to drive more sales

  • Stop reaching hard database engine limits

  • No need to change to a different database engine to fix schema limitation.

  • Defer front-end and menu customization until:

    • Time allows, or

    • The Mautic core evolves to better support it

Is This Approach for Everyone?

Not necessarily.

If you feel this approach turns Mautic into a CRM, or if you prefer not to learn SQL or use external form builders, you may be better off continuing to use Mautic as originally designed.

However, this method is commonly used by commercial developers when core platforms evolve slowly and business needs require faster innovation.

What About Learning SQL?

If you’re not familiar with SQL, don’t worry. There are plenty of free resources online, and you can learn the basics in a weekend. SQL is a simple yet powerful language and remains a cornerstone of database-driven applications.

It’s also worth noting that Symfony’s Doctrine ultimately generates SQL queries behind the scenes—so understanding SQL gives you deeper insight into how your system works.

If you prefer not to learn SQL, again, sticking with standard Mautic usage is perfectly valid.

Final Thoughts

By taking this approach, I’ve effectively freed myself from the constraints of the Mautic’s database schema and reaching database engine hard limit when running at scale. I can now build complex segments and campaign rules tailored exactly to my needs—without waiting on core updates or plugin compatibility.

If any one needs help with this solution then please send me a private message and I will be happy to help. And for those who wish to use Mautic as the developers intended that perfectly fine as well.

Thanks.