This article explores some of the significant benefits — and drawbacks — of using multi-model databases.
Table of Contents
What Is a Multi-Model Database?
There's been a continuous data explosion that's been taking place for the last two decades. This has proved to be increasingly beneficial for businesses. Organizations have been forced to devise different plans to tackle the volume and variety of data, and they've come up with two broad approaches : polyglot persistence and multi-model databases.
In polyglot persistence, you use a separate database for different types of data storage and usage patterns. For instance, if you have an eCommerce website, you might need a relational database like MySQL for transactions, a search engine like Elasticsearch for enabling product discovery, Redis for maintaining real-time trackers and other databases for other use cases. The major downside of polyglot persistence is that it adds significant overhead.
The alternative to polyglot persistence is a multi-model database or a database that natively allows you to store and access data of different types, such as relational, time series, geospatial, key-value and document. Using multi-model databases can bring a lot of benefits to businesses that deal with applications and products with various types of data constantly.
Modern SaaS applications create diverse database workloads. They often provide a real-time view of data over time, interactive analytics to explore recent and historical data, include full text search on product information and often expose an API. Each of these SaaS application functionalities have different data write needs, different access patterns and may use different data models.
In recent years, the common practice has been to use a specialized database technology for each of these data models and workloads types for a SaaS application. Each of those underlying database technologies are then stitched together to form the data infrastructure layer for the SaaS application. Multi-model databases offer a simpler alternative to this by reducing the variety of database technologies needed to serve modern SaaS applications.
In this article, you'll learn about some of the significant benefits of using multi-model databases.
Benefits of Multi-Model Databases
As previously stated, the benefits of multi-model databases are extensive and include letting you store and access data of different types and consolidate cross-model operations. In the following section, you'll learn about all the benefits multi-model databases offer.
Easier Application Development
Instead of many solutions, in a multi-model database, you have one solution. Because of this, developing and maintaining a product for your business is much more cost-effective. A multi-model database brings down infrastructure costs and directly impacts your team's availability as they won't have to spend additional time learning all the new query dialects, SDKs and consoles that come with every component of a polyglot persistence setup.
In addition, products continuously evolve over time. If a particular data model has become less valuable or redundant, you can migrate the data from that model to a new model that better suits your application's needs. And application data migration is less of a hassle with multi-model databases, as there's a lot that you don't need to think about, such as transfer costs over the network, downtime, data loss and security in transit.
Consolidation and Cross-Model Operations
Businesses collect data from various forms and sources. You can derive real value from the data when you look at business performance and metrics from different perspectives. In a polyglot persistence system, you're forced to perform additional work to enable this holistic view.
In contrast, multi-model databases are great for consolidating different data sources as they can natively support many different models. Multi-model databases reduce the work you have to do to ensure that you can look at and analyze data from various sources simultaneously.
Being able to handle transactional workloads is one of the essential requirements for a business. Although a multi-model database supports different models, such as graphs, documents and objects, it's built around the same principles as a relational database; therefore, a good multi-model database provides automaticity, consistency, isolation and durability (ACID) compliance.
There are several consistency models that a multi-model database can enforce, such as serializable, repeatable read, snapshot isolation and read committed.
A good multi-model database also provides the strongest consistency, persistence guarantee and reliability for your data. For example, SingleStore ensures that every transaction is durably persisted on a disk with a mixture of logging and replication.
Complex products usually need complex technology stacks to support them. However, what is complex invariably becomes complicated, and that's not good for your business. Having different databases for every use case adds to the overhead of processing the data downstream and tremendously adds to the operations and engineering cost as you need to manage many separate components of a system.
Multi-model databases prevent you from getting into this costly trap as they provide you with a way of simplifying your application architecture by giving you a single point of contact for the development and consumption of disparate and heterogeneous data systems with various types of data models.
Ease of Handling Many Data Formats
Database architecture and design matters. Some multi-model databases today provide multi-model support through bolting together various modules, libraries and/or open source projects. The problem with this approach is it hurts ease-of-use as the boundaries between the data models show. For instance, developers may be required to install and configure separate components for each data model.
In addition, the query language lacks composability across the data models which makes writing multi-model queries awkward. Also, the creation and management of indexes may be different in each data model. Furthermore, data storage is not unified, resulting in needless data duplication which increases storage costs.
For the best ease-of-use in a multi-model database, ensure that it provides truly unified storage, a single codebase without requiring plug-ins or additional modules and a simple indexing approach.
Reduced Need for ETL
A significant pain point for businesses is creating a separate data store for each type of workload that a SaaS application generates. Synchronizing data via ETL or CDC, and re-indexing each of the specialized data stores is difficult and time consuming. That data movement and data duplication also adds latency to the application’s user experience. Finally, each of the specialized data stores must be maintained and upgraded by skilled staff for each database technology.
Multi-model databases substantially reduce the need for ETL by supporting native integration of different models on the same platform. A smaller amount of time spent on ETL means that the data will be available to the consumers earlier when compared to a polyglot persistence setup. Also, the breadth of skillsets required to maintain a multi-model database is much less than various special-purpose databases.
Use Cases of Multi-Model Databases
Interactive SaaS applications
Modern SaaS applications need to be able to drive fast, interactive analytics on operational data in real time. Foodics revolutionizes the way companies and restaurants handle real-time reporting, inventory management, order submission and employee operations — but ran into reliability issues using several single-node, open-source databases.
To solve for their challenges, Foodics searched for a database that offered:
- The ability to place all analytics-related data in a single, unified data store
- A performant analytics engine with columnstore to democratize data access
- A multi-tenant architecture to use a single database for all customers
Foodics made the switch to SingleStoreDB, tapping into the power of a multi-model database that empowered them to deliver near 100% availability; 100x better price performance; and 60% faster query performance.
IoT Telemetry & Analytics
In the early days of the fight against the COVID-19 pandemic, real-time monitoring to prevent new, viral outbreaks was critical. Thailand-based True Digital Group sought to create a real-time visualization and alerting system that used geographic density of mobile phone locations to determine where large groups of people were gathering — and the company needed it in two weeks.
To achieve this, True Digital needed a multi-model database that:
- Could perform event stream processing on 500,000 anonymous mobile phone locations every second for 30+ million mobile phones in Thailand
- The real-time visualization must respond to ad hoc, interactive analysis by users
- The visualization must support geoanalytical queries with ultra-low latency on the order of milliseconds
Using SingleStoreDB, True Digital supports more than a trillion rows per second of raw data — comfortably handling the ingestion of 500,000 events for its customer-facing system, Tracepulse.
Streaming Media Analytics & Ad Optimization
As a leader in advertising and app monetization, TapJoy uses video ads, offers and rewards to help app publishers grow their user base and monetize mobile apps. The company had built a complex data stack that included Kafka for data streaming, Amazon RDS, PostgreSQL, MySQL and Google Big Query.
When Tapjoy ran into performance issues with their technology stack, they carried out a careful assessment of alternatives that had to meet a strict set of criteria:
- The new product needed to be multi-model, relational database — preferably a either a traditional RDBMS or NewSQL contender
- The system needed to be designed for scalability
- The new solution needed to be MySQL-compatible to create an easy transition for the TapJoy engineering team
Leaning into SingleStoreDB, Tapjoy queries (like summing financial data) went from 68 seconds to 1.23 seconds on SingleStoreDB — a 55x improvement.
The video game live streaming and esports market has grown exponentially over the past few years, presenting ample opportunity for savvy game publishers and brands to interact directly with their customers. Stream Hatchet aimed to fill this market gap — with the goal of becoming an industry-trusted source for audience analytics at the top esports events.
Stream Hatchet’s technology requirements included:
- A database capable of working with 1,000s of time-series data points in complex, multi-gigabyte aggregated queries
- Both real-time and historical data were needed for full context of live streams and esports events. Ideally, all of this data could live in the same datastore to reduce infrastructure complexity
- The database solution had to support SQL, so Stream Hatchet didn’t need to rewrite their entire backend or APIs. And, the database needed to support real-time and time-series analytics with ultra-fast performance.
Stream Hatchet landed on SingleStoreDB mainly due to its fast queries and simplified infrastructure — and that it eliminated the need for multiple purpose-built databases.
With the increasing challenges of polyglot persistence at scale, multi-model database adoption has been on the rise over the last decade. Companies like Uber, Comcast, Pandora and Dell have bought into the idea behind multi-model databases. As mentioned before, using a multi-model database, generally speaking, will help reduce the time to market for your product.
If you're interested in building future-proof applications with on-demand scalability and high availability, you should try out SingleStoreDB for free. With $500 worth of credits on any popular cloud platform, you'll be able to build scalable and resilient applications that can support a wide range of data models.