Rethinking Address Storage in Mautic: A Proposal for a More Flexible and Scalable Schema
Introduction
As Mautic continues to evolve as a powerful open-source marketing automation platform, its data model must keep pace with real-world use cases. One area where the current schema shows limitations is address storage—specifically for Companies and Contacts.
Today, Mautic allows only a single address per Company and requires address data to be duplicated across Contacts. Additionally, the address structure itself is restrictive, particularly for international use. This approach introduces inefficiencies, limits flexibility, and creates unnecessary maintenance overhead.
This post explores a proposed enhancement: introducing a separate address table that can be linked to both Companies and Contacts, while also improving how address data is structured and stored.
The Problem with the Current Model
1. Single Address Limitation for Companies
In reality, many organizations operate across multiple locations:
-
Headquarters
-
Regional offices
-
Warehouses
-
Retail sites
However, Mautic currently supports only one address per Company. This restricts accurate data representation and limits segmentation or targeting based on location.
2. Contact Address Duplication
Contacts often share the same address as their Company (e.g., office location). However, Mautic requires each Contact to store their address independently.
This leads to:
-
Repeated data entry
-
Increased storage usage
-
Risk of inconsistencies when addresses change
Additionally, modern work patterns introduce further complexity:
-
Remote workers
-
Hybrid roles
-
Multiple office affiliations
The current schema cannot elegantly support these scenarios.
3. Limited Address Field Structure
Mautic currently provides only two address line fields. While this may work in some regions, it is not sufficient globally.
In many countries, it is common to require:
-
Three or more address lines
-
Additional fields for building names, districts, or regions
Because of this limitation:
-
Users must overload existing fields
-
Address formatting becomes inconsistent
-
Data quality suffers, especially for international audiences
This highlights the need not just for structural changes, but for a more flexible and globally aware address model.
Proposed Solution: A Dedicated Address Table
Core Idea
Introduce a separate addresses table that can be associated with both Companies and Contacts, with a more flexible structure for address fields.
This structure enables:
-
One-to-many relationships (Company → multiple addresses)
-
Many-to-many relationships (Contacts ↔ shared addresses)
-
Support for more flexible and internationally compatible address formats
Key Benefits. Eliminates Data Duplication
Instead of storing identical addresses repeatedly:
-
One address record can be shared across multiple Contacts
-
Updates occur in a single place
This improves data integrity and reduces maintenance effort.
2. Supports Real-World Use Cases
With a flexible schema, Mautic could support:
-
Companies with multiple locations
-
Contacts linked to specific office sites
-
Contacts with both work and home addresses
-
International address formats with additional address lines
-
More accurate geographic segmentation
3. Improved Database Efficiency
By moving address fields out of the core Company and Contact tables:
-
Record sizes are reduced
-
Query performance can improve
-
Storage becomes more normalized
4. Unlocks Custom Field Capacity
Currently, Mautic has a practical limit of ~60 custom fields on a table before encountering MariaDB row size constraints.
Address fields consume a significant portion of this space. By relocating them:
-
Company and Contact tables become leaner
-
More room is available for custom fields
-
Users gain greater flexibility in extending their data model
5. Better Internationalization Support
Adding a third address line—and designing for extensibility—possibly by adding custom fields—means:
-
Improved compatibility with global address standards
-
Cleaner data entry for non-Western formats
-
Reduced need for workarounds and field misuse
This is a critical step for organizations operating across multiple countries.
6. Enables Future Features
A normalized and flexible address system opens the door to:
-
Address validation integrations
-
Geolocation services
-
Distance-based segmentation
-
Multi-location reporting
Migration Considerations
Transitioning to this model would require:
-
A migration script to extract existing address data into the new table which is easily done with SQL
-
Mapping current two-line addresses into the new structure
-
Backward compatibility for existing APIs and integrations
-
UI updates to support multiple addresses per entity
To ease adoption:
-
Default behavior could mimic the current single-address setup
-
Advanced users could opt into multi-address functionality
UX Implications
From a user perspective, this could look like:
-
A dedicated “Addresses” tab within Company and Contact views
-
Ability to assign existing addresses or create new ones
-
Support for multiple address lines where needed
-
Labeling addresses (e.g., “Head Office”, “Home”, “Billing”)
The experience should remain intuitive while offering greater flexibility.
Potential Challenges
While the benefits are clear, there are trade-offs:
-
Increased schema complexity
-
More joins in queries
-
Need for careful indexing and performance tuning
However, these are standard considerations in normalized database design and can be managed effectively.
Conclusion
Separating address data into its own table represents a significant improvement in how Mautic models real-world relationships. Combined with a more flexible address field structure—including support for additional address lines or even custom fields on the address table—this approach reduces duplication, increases flexibility, and better supports global use cases.
This proposal aligns with best practices in database design and addresses multiple limitations in Mautic’s current architecture.
Thanks