Leaf in the Wild posts highlight real world MongoDB deployments. Read other stories about how companies are using MongoDB for their mission-critical projects.
Leveler.com is a fast growing Software-as-a-Service (SaaS) platform for independent contractors, rapidly building out new functionality and winning new customers. However, the wrong database choice in the early days of the company slowed down the pace of development and drove up costs. That was until they moved to MongoDB.
I met with Jeremy Kelley, co-founder of Leveler.com to learn more about his experiences.
Can you start by telling us a little bit about your company? What are you trying to accomplish?
Leveler.com is a Software-as-a-Service (SaaS) platform for independent contractors, designed to make it super-easy for skilled tradespeople, such as construction professionals, to manage complex project lifecycles with the aid of mobile technology. Through the Leveler.com service, contractors can manage their customer database, generate gorgeous estimates and proposals, track work orders and client communication, organize job files and images, all the way through to managing invoicing and payment. The service can be accessed from any location and any device via our web and mobile apps.
How are you using MongoDB?
MongoDB powers our entire back-end database layer. We have implemented a multi-tenant environment, allowing contractors to securely store and manage all data related to their projects and customer base.
What were you using before MongoDB?
We started out with Couchbase. I had some previous experience of it and CouchDB from a previous company. As many of our customers are field rather than office-based, I was attracted by its mobile capabilities. But it really didn’t work out for us.
Couchbase is fast for simple key-value lookups, but performance suffered quite a bit when doing anything more sophisticated. For example:
- Range queries were slow as we waited for MapReduce views to refresh with the latest data written to the database. These types of queries bring important capabilities to our service – for example, contractors might want to retrieve all customers who have not been called for an appointment, or all estimates generated in the past 30 days.
- The N1QL API showed promise, but ended up imposing additional latency and was awkward to work with for the analytics our service needs to perform.
- Updates were inefficient as the entire document had to be retrieved over the network, rewritten at the client, and then sent back to the server where it replaced the existing document. We had to manage concurrency and conflicts in the application which added complexity and impacted overall performance of the database.
- We also found some of the features in the mobile sync technology were deprecated with little warning or explanation.
So with all of these challenges, we migrated the backend database layer to MongoDB. Our mobile apps took advantage of client side caching in the Ionic SDK for on-device data storage to replace Couchbase Mobile.
What were the results of moving to MongoDB?
Query performance improved by an average of 16x, with some queries improved by over 30x.
Our applications were faster to develop due to MongoDB’s expressive query language, consistent indexes and powerful analytics via the aggregation pipeline. We can pull a lot of intelligence on how service is consumed using MongoDB’s native analytics capability – for example “how many pageviews did a signup from Facebook generate in the first 4 hours?” or “how many pageviews in our app originated from the Estimate form view on each day?”
Before MongoDB, our development team was spending 50% of their time on database-related development. Now it is less than 15%, freeing up time to focus on building application functionality that is growing our business.
Did you consider other alternatives besides MongoDB?
We didn’t want to get burned again with a poor technology choice, so we spent some time evaluating other options.
Cassandra was suggested, but it didn’t match our needs. It was far too hard to develop against due to its data model and eventually consistent design. If we wanted to do anything more than basic lookups, we found we would have to integrate multiple adjacent search and analytics technologies, which not only further complicates development, but also makes operations a burden.
Our engineering team has a lot of respect for Postgres, but it’s static relational data model was just too inflexible for the pace of our development. We can’t afford downtime and application-side code changes every time we adapt the schema to add a new column. So Postgres, or any other relational database, wasn’t an option for us.
Please describe your development environment.
Our backend systems are developed mainly in Python, so we use the PyMongo driver to connect to MongoDB and the excellent Mogo library for object mapping. We also use the mgo driver to connect a Go application used for analysis.
Our web application uses AngularJS and React, and our mobile apps are built on Ionic.
Which version of MongoDB are you running?
We are on the latest MongoDB 3.2 release. We have to support multiple languages in our service, and so 3.2’s enhanced text search with diacritic insensitivity is a huge win for us. MongoDB’s native text indexing has enabled us to deprecate our own internally developed search engine with minimal model changes.
Can you describe your operational environment?
Our service is powered by three MongoDB replica sets running on the Digital Ocean cloud. MongoDB’s self-healing recovery is great – unlike our previous solution, we don’t need to babysit the database. If a node suffers an outage, MongoDB’s replica sets automatically failover to recover the service. Again, this means we focus on the app, and not on operations.
All instances are provisioned by Ansible onto SSD instances running Ubuntu LTS. Monitoring is via Graphite. Our backups are encrypted and stored on AWS S3.
We are also kicking off an evaluation of MongoDB Cloud Manager which we believe will bring us even greater levels of operational automation and simplicity.
How are you measuring the impact of MongoDB on your business?
We can innovate faster and at lower cost. We spend more time building functionality and improving user experience, and less time battling with the database.
We have achieved major application performance gains while requiring fewer servers. We also need less storage. MongoDB offers higher performance on sub-documents, enabling us to create more deeply embedded data models, which in turn has reduced the number of documents we need to store by 40%.
What advice would you give someone who is considering using MongoDB for their next project?
Just do it. MongoDB is a perfect fit for SaaS platforms. Unlike NoSQL alternatives, it can serve a broad range of applications, enforce strict security controls, maintain always-on availability and scale as the business grows. The result is that it will free you up to spend more time building great services.
Jeremy, thank you for taking the time to share your experiences with the community.
If you are wondering which database to use for your next project, download our white paper: Top 5 Considerations When Evaluating NoSQL Databases.
About the Author - Mat Keep
Mat is a director within the MongoDB product marketing team, responsible for building the vision, positioning and content for MongoDB’s products and services, including the analysis of market trends and customer requirements. Prior to MongoDB, Mat was director of product management at Oracle Corp. with responsibility for the MySQL database in web, telecoms, cloud and big data workloads. This followed a series of sales, business development and analyst / programmer positions with both technology vendors and end-user companies.