-
Create solutions that bring maximum success and value under our expert product management guidanceEnsure your product idea viability and get the right market and development strategies to succeedGet a product that directly addresses your customer needs and matches the goals of your businessBring your customers an exceptional user experience and make your product stand out with our designGet designs that amplify your product features with clear, intuitive, and sales-boosting user experienceNurture customer loyalty, boost sales, and expand your market presence with a stand-out mobile appGet higher customer satisfaction, more conversions, and better competitiveness with our UX auditCreate a custom software solution to unlimit your business capabilitiesStart and grow your startup fast or effectively renovate your existing solution with our RoR expertsExtend your product line quicker and cheaper by creating a secure, reliable, and flexible API solutionGet expert technical assistance in building real-time React-based web applications and SPAsCreate robust native or cross-platform mobile apps for your business with our expert assistanceGet native-like mobile apps for both Android and iOS using the best cross-platform technologiesCreate native iOS, iPadOS, and tvOS applications to cover any of the desired Apple user segmentsCreate 99.9% crash-free native Android applications for any available device and screen typesEnsure the top quality and bug-free performance of your products by fixing all issues at early stagesConsult our experts to build an efficient quality assurance strategy for your productEnable full lifecycle software testing services to detect and fix all product issues at the earliest stageReveal all non-typical performance, security, and usability issues with our manual QA servicesBoost your overall software development velocity with our robust automation testing solutionEnsure the usability, security, performance, compliance, and compatibility of your web appsProvide your customers with mobile apps free from any usability, security, and performance issuesUse our functional testing services to ensure every product feature works as expected in all scenarios.Make technologies work for your business growth and choose the right ones to achieve specific goalsImprove app performance, setup continuous delivery, cut infrastructure costs with our DevOps servicesKeep your product stably up, running and get timely feature upgrades with our maintenance servicesClean your software from code issues and uncover possible improvements to boost its performanceEnsure security of your healthcare products and achieve HIPAA compliance with our expert assistance
-
Multi-Vendor Marketplace Online Store Custom Marketplace Telemedicine Software Chat App Custom Booking System Video Conferencing For Enterprise For StartupsBuild a custom multi-vendor marketplace fast and cost-efficiently using our MarketAge solutionLaunch a custom B2B marketplace for any type of products with MarketAgeLaunch a unique, custom-functional B2C marketplace at minimum effort with MarketAge white-lable productReduce costs to build an easy-to-use and reliable C2C marketplace using our MarketAge solutionCreate an online store with unique design and features at minimal cost using our MarketAge solutionGet a unique, scalable, and cost-effective online marketplace with minimum time to marketGet a cost-efficient, HIPAA-compliant telemedicine solution tailored to your facility's requirementsGet a customizable chat solution to connect users across multiple apps and platformsImprove your business operations and expand to new markets with our appointment booking solutionAdjust our video conferencing solution for your business needsScale, automate, and improve business processes in your enterprise with our custom software solutionsTurn your startup ideas into viable, value-driven, and commercially successful software solutions
-
Streamline and scale your e-commerce business with a custom platform tailored to your product segmentsAutomate, scale, secure your financial business or launch innovative Fintech products with our helpCut paperwork, lower operating costs, and expand yout market with a custom e-learning platformUpgrade your workflow, enter e-health market, and increase marketability with the right custom software
-
Discover our software engineering culture, what principles we follow to make our clients succeedOur BA office helps clients choose the right development strategy and get maximum value at minimum riskFind out how we manage development risks, ensure on-time delivery, and prevent budget overrunsWe create clear, intuitive, and functional designs to solve specific business problems of our clientsSee what techniques and principles we follow to engineer top-tier software products at RubyGarageSee how our QA office ensures zero usability and functional issues in every product we deliver to clientsDiscover more of RubyGarage’s culture, values, and strengthsDevelop your product in a clear workflow aimed to save your time and budget and boost the qualityJoin our team to build a successful career in software development. See open positions at RubyGarage
- Case Studies
- Blog
Three Database Architectures for a Multi-Tenant Rails-Based SaaS App
Multi-tenant Software as a Service (SaaS) applications are extremely popular products. Why is that?
Let’s imagine you want to create a web app and provide it to several organizations as a white label product. How might you implement such a project? You could simply copy the entire codebase for each organization. But this means you’ll have to support multiple application instances separately. That’s not the best solution, as your development team will have to manage server infrastructure and update features independently for each app instance.
Let’s now imagine that you provide your app to a dozen tenants and deploy a new app version for each of them. To update all applications, your web team will have to do the same thing a dozen times! There is a much better solution – you can develop a multi-tenant Software as a Service application.

Multi-tenancy means that multiple organizations – otherwise called tenants or groups of users – can employ the very same application. With a multi-tenant SaaS app, your web development team will need to deploy and support only one codebase – not multiple applications. You’ll be able to update your SaaS app simultaneously for all tenants, and it’ll be easier to support the server infrastructure. Overall, multi-tenancy greatly simplifies development of a Software as a Service app.
But before you build a multi-tenant SaaS application, you’ll need to address one major problem – how to securely isolate each client’s data. Thus, the database layer will require special attention. We’ll introduce three approaches to designing the database layer.
We’ll be talking about how to build a multi-tenant SaaS app with Rails, and to design the database layer for a multi-tenant Rails-based SaaS application, you’ll need the Apartment Ruby library. The other Ruby libraries we should mention are Detectify and Houser. Your development team can use those libraries to build database requests. You’ll also need a relational database, such as PostgreSQL or MySQL, to save tenant data in the Rails app. These Ruby libraries and databases that we’ve just mentioned will help you complete specific tasks, and we’ll review them in detail.
Multi-Tenant SaaS Application and Database Design
As we’ve suggested, the major architectural concern with multi-tenant SaaS apps is the database layer, which is also called the persistence layer. There are three aspects of database design that we’ll address:
- The level of tenant data isolation;
- Difficulties with restoring data;
- Difficulties with data encryption.
A multi-tenant application architecture can adopt one of three database architectures. The first option is to use a separate database for each tenant. The second option is to use the same database for all tenants, but to give each tenant their own schema with individual tables. With either of these two approaches, we recommend using Apartment, the Ruby gem we mentioned previously.
But there’s also the third option: tenants share a schema within the same database. Note that Apartment won’t work in this case. Your development team will need to implement this design manually.
We’ll provide more details about the workings of the Ruby libraries we’ve mentioned, but first let’s dive into how to organize the database layer.
Single Database for Single Tenant
The main advantage of “one database–one tenant” design is that it ensures the highest level of data safety. Each database instance is located on a separate server, so instances are physically separated. This means that one tenant simply can’t access another tenant’s data.

Another advantage of this approach is that it’s flexible. Imagine a situation when one tenant wants to encrypt data but others don’t. Do you have to encrypt the data of all tenants? Actually, you don’t! Since tenants have fully isolated databases, we are free to encrypt the data of any tenant (or not).
The complete isolation of databases also helps us to easily restore data. Whenever a tenant’s data gets corrupted, we can retrieve it from a backup database without implementing complex logic.
Given these advantages, using individual databases for tenants seems like a slick solution. But there’s always a catch. As we mentioned before, multi-tenant Software as a Service applications are designed to reduce the cost of server infrastructure. However, when you provide a dedicated database for each tenant, you have to use a separate server instance to store each database. Hence, you’ll have to pay for additional servers, driving up the cost of using the application. Besides, the ‘separate database’ approach complicates the server infrastructure, making it more difficult to support.
Tenants may not want to save their data alongside that of other tenants. If tenants need the highest data safety and flexibility, and are ready to pay for it, then the “single database” design is a perfect choice. You can implement this design for a full white-label web application (it's understood that a full white-label app has a unique domain name; a partial white-label app would have only a unique subdomain name).
But there is a database design that is cheaper and still provides partial isolation: the “separate schemas” design.
Separate Schema for Each Tenant
To lower the operating costs of the database layer, you can opt for a ‘separate schema’ design.
With this design, the app connects to a single database instance. Each tenant has their own schema (a set of tables) within the database, but not an entire database. Using separate schemas lets you reduce the complexity of server infrastructure, and thereby the cost. The separate schema design provides another benefit as well: it’s very flexible. Although initially each new schema has standard tables, tenants are able to customize their schema however they want.

There are some disadvantages of the separate schema design, however; for one, we have to pay attention to how we back up and restore data. Let’s say that one tenant’s data gets corrupted, while the data of all other tenants is intact. To avoid overwriting the entire database, developers will have to implement special techniques.
One approach would be to copy tenant data from a backup server to a separate server. After that, we could retrieve the data from the necessary schema. Finally, we could use this data to replace the corrupted information in the main database. As you can imagine, this process is time consuming.
Separate schemas provide only partial data isolation, but are a cheaper alternative to fully isolated databases. The separate schema design is equally good for both partial and full white-label SaaS applications.
So far, we’ve reviewed two approaches to designing the database layer that provide a high enough level of data isolation. There’s one more option left – a shared schema for all tenants.
Shared Schema for Tenants
Using a shared schema for all tenants is an easy-to-implement approach, at least at the initial stages of development. Let’s sort through how a shared schema works. In the simplest sense, the data of all tenants will be stored in the same tables. To find and retrieve data from each row, which is assigned to a specific tenant, your SaaS application will use a tenant ID.
The shared schema design provides a few benefits. There’s no need to create and adjust schemas for tenants, unlike with the separate schema approach. There’s also no need to run additional servers for databases.

But what about the disadvantages of using a shared schema? Hopefully, your app will gradually add more and more tenants over time. Assuming it does, then eventually it will become increasingly difficult to query, index, and update data. Besides, it’s also difficult to retrieve data for a given tenant. The multi-tenant SaaS app first has to verify the tenant access level; then the app must also verify the user access level, and only after that can we build a request to the database. With this design, each request will be fairly complex.
Given the advantages and disadvantages of each approach, we recommend using separate schemas, as they provide the best balance between difficulty of development and cost of running the database layer. But you should take into consideration the level of data safety your tenants will require. All three approaches guarantee enough security level for certain applications, and your Service Level Agreements must stipulate the level of security you provide: either full or partial isolation.
So that’s how to implement the database layer in a Software as a Service application. Now we need to talk about what tools you can use to develop this layer for a Ruby on Rails-based SaaS app.
Implementing Database Design in a Rails-based SaaS App
Apartment is a top Ruby library that separates tenant data. Basically, you can create tenants using Apartment, and the library will automatically assign a new isolated schema to each tenant. This is the second approach that we discussed. But Apartment can create isolated database instances as well.
As we can see, Apartment allows us to build Rails-based SaaS apps with full or partial white-labeling right away. And to get the most from Apartment, you should use a PostgreSQL database.
How does Apartment work? Apartment fetches data from the schema that corresponds to the elevator – domain, subdomain, or full host name. The library simply analyzes each request to the database using elevators. By default, Apartment splits tenants by subdomains, but you can quickly set it up to use domains.
Keep in mind that for the third approach – a shared schema – Apartment won’t work.
To implement a shared schema approach, your development team only needs to assign IDs to tenants and send database requests with those IDs. And if you’re going to provide custom domains or subdomains for your clients, you’ll need either Detectify or Houser.
Houser is a multi-tenancy gem that can send database requests using subdomain names. But Houser is a relatively old Ruby library. For modern Rails-based SaaS apps, we wanted more flexibility. That's why we've developed Detectify to replace Houser.
Detectify can create database requests using both domains and subdomains. It also lets the app ignore routes when sending a URL-based request to the database. Overall, Detectify is a more advanced multi-tenancy gem than Houser. For more information, you can read our Detectify review.
Developing a multi-tenant Software as a Service application with Rails goes well beyond designing the database layer. But if you choose one of these three database architectures at the start, it will be easier to develop, support, and scale your web application in the long run.
Subscribe via email and know it all first!