You are designing a SaaS product, or rebuilding one, and you have to decide whether customers share a database. A large prospect asks whether their data sits next to anyone else’s. Your cloud bill depends on the answer, and so does your next security review.
\nA tenant is one customer account in a SaaS product: in business software, a company and all of its users. Running many tenants on one shared system is a large part of what makes SaaS cheaper to operate than one installation per customer, as explained in What is SaaS?. How much you share, and how you keep tenants apart, is the architecture decision this guide covers.
\nThink of housing. In a street of detached houses, each family has its own walls, pipes and bills. In an apartment building, families share the foundation and the plumbing, and each has a locked door. Some buildings mix the two: most flats share everything, a few penthouses have a private lift. Detached houses are private and expensive. Apartments are cheap, and only as safe as their locks.
\nCloud vendors use names for the same three choices. In AWS’s terms, the silo model gives a tenant dedicated resources, the pool model shares resources among tenants, and the bridge model mixes the two. AWS adds that a silo still shares one identity, onboarding and operations layer for all tenants. Without that layer, you are running a managed service, not SaaS.
\nMicrosoft’s Azure Architecture Center splits the middle ground in two. The table maps both vendors’ terms.
\n| Model (AWS / Microsoft) | \nWhat is shared | \nHow tenants are kept apart | \nCost per tenant | \nMain risk | \n
|---|---|---|---|---|
| Silo / automated single-tenant | \nIdentity, onboarding, operations | \nSeparate infrastructure per tenant | \nHighest: Microsoft notes 100 tenants “probably require 100 times that cost” | \nUpdates and fixes across many deployments | \n
| Pool / fully multitenant | \nEverything | \nApplication code and a tenant ID | \nLowest | \nA bug leaks data; one heavy tenant slows the rest; one bad change hits everyone | \n
| Bridge / vertically partitioned | \nMost tenants pooled, some on dedicated deployments | \nBoth, depending on the tenant | \nMiddle | \nCode must support both modes, and moving a tenant is a migration | \n
| Bridge / horizontally partitioned | \nThe application tier; each tenant gets its own database | \nSeparate data, shared compute | \nMiddle | \nAutomating many per-tenant components | \n
The vertical split is often a pricing decision too. Microsoft points out that you can charge more for a single-tenant deployment to recover its cost.
\nFor row-level isolation, the database can enforce the filter for you. PostgreSQL’s row security policies restrict which rows normal queries return. With row security enabled and no policy defined, PostgreSQL applies “a default-deny policy”, so no rows are visible. But superusers and roles with the BYPASSRLS attribute always bypass it, and table owners normally do too, unless the table is set to FORCE ROW LEVEL SECURITY. If your application connects as the table owner, the policies may not apply to it.
AWS makes a point that many teams miss. Authentication tells you who the user is, and authorization tells you what they may do. Neither stops a request from reaching another tenant’s data. In AWS’s words, “a user could be authenticated and authorized, and still access the resources of another tenant.” Isolation means every data access is scoped by the current tenant’s context, enforced separately from login.
\nIn a shared system, one tenant’s load becomes everyone’s problem. Microsoft’s example: if a large tenant runs a heavy query or operation, “it might affect other tenants.” The usual controls start with per-tenant rate limits and quotas. Beyond that, you can move the heaviest tenants to dedicated resources (the vertical split). Or you can give each tenant its own copy of the component under the most load (the horizontal split).
\nExample: a labeled hypothetical with round prices. You have 200 tenants. A shared database cluster that serves all of them costs $1,500 a month. The smallest dedicated database costs $25 a month. Each schema migration takes 3 minutes to run and check per database.
\nThe pool is cheapest by a wide margin: $1,500 against $5,000. Database per tenant costs 3.3 times as much ($5,000 / $1,500) and adds 10 hours to every release. The bridge keeps the pool’s economics for 190 tenants ($1,500 / 190 = $7.89 each) and turns isolation into a product the 10 large tenants pay for.
\nWhere the infrastructure runs matters as well. For the AWS building blocks, see SaaS on AWS. For serving each tenant on its own domain, see Cloudflare for SaaS. If a customer asks for a copy in their own data center, that is a different model, covered in SaaS vs on-premise.
\nMulti-tenant SaaS runs many customers on shared infrastructure, and the choice is how much to share: everything (pool), nothing but identity and operations (silo), or a mix (bridge). In the example, 200 tenants cost $1,500 a month pooled and $5,000 on dedicated databases, while a bridge keeps pooled costs and charges 10 large tenants for isolation. Whatever you choose, enforce tenant scope on every data access, keep the app from bypassing database policies, and test that one tenant cannot read another’s data.
\n", "image": "https://saascron.com/media/multi-tenant-saas-architecture/16x9.jpg", "date_published": "2026-10-28T12:00:00-04:00", "date_modified": "2026-10-28T12:00:00-04:00", "authors": [ { "name": "Ricardo Machado", "url": "https://saascron.com/author/ricardo-machado/" } ], "tags": [ "Building SaaS", "Multi tenancy", "Architecture", "Data isolation", "Databases" ], "language": "en-US" }, { "id": "https://saascron.com/headless-saas/", "url": "https://saascron.com/headless-saas/", "title": "Headless SaaS: what API-first software means for builders", "summary": "What headless and API-first SaaS mean for content, commerce and payments, what you gain and what it costs to build and run, with a caching example and a checklist.", "content_html": "A vendor has told you its product is “headless” or “API-first”, and you need to know whether that helps your team or just adds work. The terms describe one design choice. Headless SaaS is a hosted service that runs the back end (data, rules, checkout, accounts) and hands you an API instead of a finished front end. You build the screens your customers see.
\nThat choice moves cost and control from the vendor to you. This guide explains what headless means for content, commerce and payments, what you gain, what it costs, and how to tell whether it fits. For the basics of software delivered as a service, see What is SaaS?. For the difference between a SaaS product and a platform you build on, see SaaS platform.
\nThink of a restaurant kitchen that does not have a dining room. It cooks for anyone who orders: a delivery app, a food truck, a stand at a stadium. Each outlet has its own look and its own menu board. The kitchen only promises that when an order comes in, the food goes out.
\nA traditional SaaS product is the restaurant with the dining room: the kitchen and the tables come together, and the tables look the way the owner decided. A headless product is the kitchen alone. The “head” is the front end, the part people see and click. The API (application programming interface) is the order window: a defined way for your code to ask the service for data or to make it do something.
\nShopify’s developer documentation puts it in one line: “Headless commerce separates your storefront’s frontend from its backend” (Shopify, headless).
\nAPI-first is the design habit behind it. The vendor designs the API as the main product, and any screens it ships are built on that same API.
\nThe pattern is the same each time. The vendor runs the hard back-end parts, and the more of the front end you take on, the more control and the more work you get.
\n| Question | \nCoupled SaaS (vendor’s front end) | \nHeadless SaaS (your front end) | \n
|---|---|---|
| Who builds what customers see | \nThe vendor, through themes and templates | \nYour developers | \n
| Time to launch | \nDays to weeks | \nLonger: you build and test every screen | \n
| Design freedom | \nWithin the vendor’s templates | \nAnything your team can build | \n
| Channels | \nUsually one: the vendor’s site | \nAny: web, app, kiosk, partner sites | \n
| Hosting the front end | \nIncluded | \nYours, or the vendor’s add-on | \n
| Who fixes a broken page | \nThe vendor | \nYou | \n
| Cost profile | \nMostly the subscription | \nSubscription plus build, hosting and maintenance | \n
Shopify is unusually candid about the last row: “A headless storefront costs more to build and run than a theme.” It says to confirm the merchant accepts the added cost and complexity, and has developers to maintain the storefront after launch.
\nTwo costs surprise teams that move to headless: API traffic and maintenance hours.
\nExample: a hypothetical store with 300,000 page views a month. Each page makes 3 API calls to the commerce and content services.
\nCheck each vendor’s rate limits and pricing against the uncached number, not only the cached one.
\nMaintenance is the second cost. Suppose the front end needs 12 developer hours a month for fixes, framework upgrades and new campaign pages, at a loaded cost of $90 an hour.
\nWith a coupled product, most of that work is the vendor’s, priced into the subscription. With headless, it is a line in your budget for as long as the storefront exists.
\nTick each line before you choose a headless product:
\nIf you tick fewer than four, a coupled product with an API for the parts you need is usually the safer start. Connecting it to the rest of your stack is covered in SaaS integration. For online stores in particular, see ecommerce SaaS.
\nHeadless SaaS runs the back end, such as content, commerce, payments or accounts, and gives you an API instead of a finished front end, so you build every screen your customers see. You gain design freedom and any number of channels, and you take on the build, the hosting and every fix after launch. Choose it when templates cannot do what you need and you have developers to own the front end; otherwise, start coupled and use the API only where you need it.
\n", "image": "https://saascron.com/media/headless-saas/16x9.jpg", "date_published": "2026-10-25T17:00:00-04:00", "date_modified": "2026-10-25T17:00:00-04:00", "authors": [ { "name": "Ricardo Machado", "url": "https://saascron.com/author/ricardo-machado/" } ], "tags": [ "Building SaaS", "Headless", "API first", "Cms", "Ecommerce", "Architecture" ], "language": "en-US" }, { "id": "https://saascron.com/cloudflare-for-saas/", "url": "https://saascron.com/cloudflare-for-saas/", "title": "Cloudflare for SaaS: custom hostnames, customer SSL and pricing explained", "summary": "How Cloudflare for SaaS puts your customers' own domains on your app with managed certificates, and what it costs at 50, 500 and 5,000 hostnames.", "content_html": "You run a SaaS product, and a customer asks to reach their account at app.theircompany.com instead of theircompany.yourapp.com, with a valid padlock in the browser. Then ten more customers ask. Cloudflare for SaaS is the Cloudflare feature built for this: it accepts traffic for your customers’ domains, gets a TLS certificate for each one and forwards the requests to your application.
Custom domains are one of the first “enterprise” requests a young SaaS product receives, because a customer’s brand on the address bar matters to them. This guide explains the moving parts, the setup and the price. For the bigger picture of how a request travels from a browser to a SaaS vendor’s servers, see SaaS in cloud computing; for the basic model, What is SaaS?.
\nThink of the reception desk in a shared office building. Letters arrive addressed to forty different companies, and the desk accepts all of them, checks each one, and carries it to the right floor. Nobody outside needs to know that the forty companies share one building.
\nCloudflare for SaaS is that desk for web traffic. The vocabulary is short:
\napp.theircompany.com, that you add to your own Cloudflare zone.customers.yourapp.com, that your customers point their DNS at.The customer keeps their domain and their DNS provider. They add one record. You do the rest from your Cloudflare account or its API.
\nCloudflare’s getting started guide describes four steps, in this order.
\n*.customers.yourapp.com, that points at the fallback origin. Cloudflare calls this step “optional, but highly encouraged,” because it gives customers a stable name to point at.app.theircompany.com to your CNAME target.Before the customer switches DNS, check that the hostname’s status and its SSL status both read active. Switching earlier sends their users to a page with a certificate error.
You have two options, per Cloudflare’s certificate management page. Cloudflare can manage “all the certificate issuance and renewals on your behalf,” or you can upload certificates you already hold when you need to control the private keys.
\nWith managed certificates, the certificate authority still has to validate each domain. The API offers three methods: http, txt and email. HTTP validation works once the hostname already points at your CNAME target. TXT validation means the customer adds a DNS text record, and it is required for wildcard hostnames. A third option, delegated DCV, has the customer add a one-time DNS record so that future renewals validate without them (validation methods).
The choice shapes your onboarding email. HTTP validation asks the customer for one record, but only after they point their domain at you. TXT validation asks for two records, but you can have the certificate ready before the switch.
\nCloudflare publishes the price on its plans page, as of October 2026:
\n| Zone plan | \nCustom hostnames included | \nEach additional hostname | \nMaximum | \n
|---|---|---|---|
| Free, Pro, Business | \n100 | \n$0.10 | \n50,000 | \n
| Enterprise | \nCustom | \nCustom pricing | \nUnlimited (contact sales above 50,000) | \n
So the price is $0.10 per additional custom hostname (Cloudflare plans page), on top of whatever plan your zone is on. The plans page does not state a billing period for that fee, so check how it appears on your own Cloudflare invoice before you budget.
\nExample: every customer of your SaaS product uses one custom hostname. On a Free, Pro or Business zone, the first 100 hostnames are included and each one after that is $0.10:
\n| Customers with a custom domain | \nBillable hostnames | \nHostname fee | \nFee averaged over all customers | \n
|---|---|---|---|
| 50 | \n0 (inside the 100 included) | \n$0 | \n$0 | \n
| 500 | \n500 - 100 = 400 | \n400 x $0.10 = $40 | \n$40 / 500 = $0.08 | \n
| 5,000 | \n5,000 - 100 = 4,900 | \n4,900 x $0.10 = $490 | \n$490 / 5,000 = $0.098 | \n
The average fee per customer approaches $0.10 as you grow, because the 100 free hostnames matter less each time. At 5,000 customers it is just under 10 cents per customer, whatever the billing period turns out to be on your invoice. The real limits are elsewhere. Above 50,000 hostnames you need an Enterprise contract, and each hostname adds support work when a customer’s DNS is wrong.
\nCloudflare for SaaS fits when you have, or expect, dozens to thousands of customer domains and do not want to run certificate issuance yourself. It also puts Cloudflare’s network in front of every customer domain, which is the “reception desk” doing its other job: filtering traffic before it reaches your servers.
\nYou have other routes. You can run your own reverse proxy and request certificates from a public certificate authority such as Let’s Encrypt through the ACME protocol. Several CDNs and hosting platforms sell their own custom-domain features. The trade-off is the usual one for a SaaS buyer: a per-unit fee in exchange for not owning the operational work. With fewer than 100 custom domains on a Cloudflare zone, the per-hostname fee is zero, so the question is mostly about lock-in and operations, not cost.
\nactive, or use TXT or delegated validation so the certificate exists before the switch.Cloudflare for SaaS lets your customers point their own domains at your application while Cloudflare validates, issues and renews a certificate for each one. Setup is a fallback origin, a CNAME target, one custom hostname per customer and one DNS record on the customer’s side. On Free, Pro and Business zones the first 100 hostnames are included and each extra one costs $0.10, so 5,000 customer domains mean 4,900 billable hostnames and a $490 fee.
\n", "image": "https://saascron.com/media/cloudflare-for-saas/16x9.jpg", "date_published": "2026-10-17T07:00:00-04:00", "date_modified": "2026-10-17T07:00:00-04:00", "authors": [ { "name": "Ricardo Machado", "url": "https://saascron.com/author/ricardo-machado/" } ], "tags": [ "Building SaaS", "Cloudflare", "Custom domains", "Ssl", "Multi tenant" ], "language": "en-US" } ] }