library · tech brief

Why every nursery gets its own database.

Most cloud software quietly pools every customer into one giant shared database, kept apart only by a column that says which row belongs to whom. The single-tenant approach makes the opposite call: one business, one database, no exceptions. It costs more to run. Here is why that can be the right choice for a system that holds an entire operation.

the decision

One business, one database. No exceptions.

Your data, your database. A single-tenant system never mixes two businesses together inside the same database. That is the foundation everything else is built on.

the road most software takes

The shared table almost everyone uses.

Most software-as-a-service is built multi-tenant: every customer's records live side by side in one enormous shared database, separated only by a tenant_id column marking which row belongs to whom. It is cheaper to run and quicker to ship — one database to maintain, one copy of everything for everybody.

It also means your pricing, your customer list and your margins sit in the same tables as a hundred other businesses, including, quite possibly, your competitor down the road. The wall between you is a single value in a single column. Most of the time that wall holds. But "most of the time" is doing a lot of work in that sentence — a mistaken query, a missed filter, a bug in someone else's feature, and the separation that was only ever logical can leak.

Single-tenant systems take a different road on purpose. Each running copy, often called an instance, belongs to exactly one business, and its data lives in its own database. The separation is not a column you have to trust; it is physical.

hard isolation

Your numbers are never pooled with anyone else's.

Growers are rightly protective of their pricing, their customers and their margins — that information is the business. When every tenant has its own database, there is no shared table for it to leak from, and nothing of yours sitting next to a competitor's.

This is the single-tenant story told as a privacy promise rather than an architecture diagram: your commercial data stays yours, and is never one missed WHERE clause away from being visible to a business it was never meant for. Separation you can reason about, because it is real rather than conditional.

shaped to you

A system that bends to your nursery.

An ERP holds the whole shape of a business, and no two nurseries are shaped alike — a wholesale grower, a garden centre and an online seller want different things from the same software. When each business has its own instance, yours can be tuned to how you actually work without that change rippling out to anyone else.

A single-tenant foundation lets one business's setup be moulded to how it works while every other customer's stays exactly as it was. Nobody's configuration has to be negotiated against everybody else's.

the honest part

It costs more. Here is why it can be worth it.

A database per tenant is more infrastructure to provision, run and back up than one shared table would ever be. There is no pretending otherwise. The question is when that bill is worth paying.

There is a real cost to this decision, and it is only fair to name it. Giving every customer their own database means provisioning and maintaining many databases instead of one, backing each up separately, and carrying more operational weight per business than a shared-table system ever would. Multi-tenant is the cheaper architecture, which is precisely why most software chooses it.

The case for the more expensive road rests on what an ERP actually is. This is not a newsletter tool or a booking widget where a pooled database is a reasonable bet. It is the system of record for an entire operation — the stock, the customers, the prices, the money, the lot. For something holding that much of a business, hard isolation, a setup that can be shaped to it and a fault that stays contained are worth more than the saving of crowding everyone onto one table.

a smaller blast radius

A problem in one instance stays there.

When everyone shares one database, everyone shares its bad days too. A heavy report one business runs, a migration that goes wrong, a corruption in one place: all of it can ripple across every customer at once, because there is only one place for it to happen.

Separate instances contain that. Each business is its own self-contained system, so a fault, a fix or a heavy workload in one does not spill into yours. The blast radius of almost anything that can go wrong shrinks from "everyone" to "one", and that one is never you because of something a stranger did.

one thing, not a slice

A database is something you can hand over.

Every supplier will promise you your records back. What decides whether the promise can be kept is the shape of the storage behind it. Carving one business out of a shared table is a project, negotiated and scheduled and done at whatever fidelity the vendor chooses. Copying a database is an afternoon.

That is the practical dividend of the architecture. Your records are a discrete object with your name on it, complete and countable, rather than a filtered slice of a database you share with strangers.

atlas core

How Atlas Core gives every nursery its own database

Atlas Core runs single-tenant by design — one nursery, one instance, one database:

Physical data isolation per nursery. Your pricing, customer list and margins live in their own database, never in a shared table beside another grower or a competitor down the road.
An instance shaped to your operation. Wholesale grower, garden centre or online seller, the system shows only the modules that match what you do, and your configuration is never negotiated against other customers.
A smaller blast radius. A heavy seasonal report, a failed migration or a data problem in one nursery's instance stays contained there and never ripples across every customer at once.
Ownership as a countable object. Your records are a whole database that can be copied and handed over, because they were never pooled with anyone else's.
Privacy you can reason about. Separation that is physical, rather than one missed WHERE clause in someone else's feature away from leaking.

Read further

Field guide · 2026

What a growing plant actually costs

A plug arrives at 40 cents and ships as a 3-litre worth twenty times as much - its cost changed while it stood still. Why batch-level costing keeps nursery stock valuation honest where an off-the-shelf ERP can't.

6 min read · Apr 2026 Read →

Field guide · 2026

Why mother plant management matters more than ever

Clean stock, traceability and ageing clone lines are converging into one discipline - and the humble stock-plant register has become the nursery's most consequential record.

6 min read · Mar 2026 Read →

Field guide · 2026

EU plant passports, end-to-end

What a plant passport is, the four fields it carries, who must issue one, and how one-step-back, one-step-forward traceability keeps it audit-ready.

7 min read · Mar 2026 Read →

Your numbers, in a database of their own.

One business, one database: hard isolation, a smaller blast radius and a setup shaped to your nursery. Talk to us about how Atlas Core fits the way you work.

Talk to us