Table of Contents
Between loans, customers, payments, custom fields, rules, and all the dozens of other things you can save and configure in LMS, there's a lot of information to keep track of. Our built in reporting tools and the API are both great tools for pulling information, but many of our larger lenders want a faster way to get their info. Instead, you can go directly to the source: LoanPro's database. This read-only database is a replica of all the information throughout your entire tenant.
This article will explain the basic reasons why you would want to use the database. But if you already understand why databases are useful, our article How the Database Works explores how the data is structured and how you can pull information from it. Like this article, you can understand it without a background in technology or information science.
Use Case: Convenience
Use Case: Database/Large Reports
A lender wants to analyze how the information they use to decide whether an applicant should get a loan correlates to how well the borrower ultimately repays the loan. The lender determines that in order to do this, they will need to pull 200,000 loan records each month. They try pulling this information through reports, but the data has to be compiled from several reports. But because there is so much data, each report can take several hours to generate. The process works, but it eats a whole day for their data team.
LoanPro provides direct access to a read-only replica of the lender's database, letting you view all loan data from a single source. Because retrieving information from the database is so fast, getting 200,000 loan records will take just a few minutes, instead of hours. And since it takes a fraction of the time, your data team will be able to get more timely and useful reports to you, boosting your teams efficiency and helping you make better decisions about what loans to offer and how to service them.
We should start by exploring what the database really is. When you save information in LMS, like creating a new loan or updating a custom form, that information gets saved in the database. And when you pull up a customer's page to check their references, the system draws that information up from the database. The database isn't just an additional ledger of what's happening in the software, it is the ledger.
The database is the source of truth: Whether you manually check in the UI, perform a report, pull info with the API, or query the database directly, the information is all the same, and it all comes from the database. ("Query" is the verb developers use to mean search the database.)
But if information is the same, you might wonder why anyone would bother with the more technical process of querying the database. There's a few reasons:
- Speed – If you know how to perform a database query, it's the fastest way to get information. Imagine going to the library to find a specific book. Using our report tools is like waiting in line and ask the librarian for help—not as fast as pulling a book directly off the shelf, but easy. If you know a bit about how the library is organized, you could use the librarian's index cards (read: API) and find the book yourself, saving you some time. But the fastest option would be to just walk inside, go straight to the right shelf, and grab your book. It's hands-down the fastest way to get your information, but it requires that you know exactly which shelf the book is on, where the shelf is located, and where the book is on the shelf.
- Multiple Tenants – Reports in LMS can search through all the loans in your tenant, but if you use multiple tenants, you're only getting part of the picture. Each tenant has its own database, but through the database, you can query multiple tenants and combine the information into a single source, getting a comprehensive view of your entire operation.
- Third-Party Data Analysis – If you get analytics from software other than LoanPro, the database may be the best tool for getting data out of our system and into theirs.
Where Does the Database Fit?
We typically see larger lenders using the database, and smaller operations using our built-in reporting tools. If you have less data inside of LMS, then reports can pull and organize that data relatively fast. It's only once a lender has a large amount of data that reports begin to take longer to generate, at which point it makes more and more sense to get your data directly from the database.
This Feature is Not
Let's clear up some common misunderstandings about the database:
- The database isn't magic. Running a query requires some technical know-how. It's not impossibly difficult, but it is the kind of thing people go to college for. Most lenders who use the database will have a specialized data expert or team whose main responsibility is querying the database and analyzing the data. If you don't have the resources for a data team, you can enlist the help of our own data experts and support team. Alternatively, you could use the report tools built into LMS.
- The database doesn't include data from Secure Payments or Connections. LMS, Secure Payments, and Connections are separate applications, so their data are all stored in separate places, but we only give lenders database access to LMS. To keep borrowers' payment data safe, we don't allow database access to Secure Payments. And Connections only has a few tenant-level controls, so there's no real need to query the database.
- You can't directly edit the database. Unlike the API, which allows you to both pull and update information, the database only lets you read the information that's already there. You can't use a database query to update or service loans. You can, however, use that query to generate a .csv file, which you could then use in an Import.
If you're curious about databases but don't have a strong technical background, we recommend reading How the Database Works. It explains how the data is structured and how people can pull information from it. And if you want to dive in and see some actually database tables, our Database Table Index is the place to start.