When you sign up for an ERP, there is a question you probably never think to ask: is my data sharing a database with other companies?
The answer matters more than most vendors let on.
Three models for running multiple clients
Single-tenant: Every client gets their own copy of the entire application and their own database. This is the SAP on-premise model. Safe, but expensive. Every client is a separate deployment. Every update has to be rolled out individually. Every bug fix is a project.
Shared-database multi-tenant: All clients share one database. Their data is separated by a "tenant_id" column on every table. This is what most cloud ERPs do. It is cheap to run. It is also a single misconfigured query away from Client A seeing Client B's data.
Isolated-database multi-tenant: All clients share one application (one codebase, one deployment), but each client gets their own database. The application routes requests to the right database based on who is logged in.
SimpleGrid uses the third model. Here is why.
The shared platform
There is one SimpleGrid application. One codebase. One NestJS backend. One React frontend. One deployment. When we fix a bug, every client gets the fix. When we add a feature, every client gets access. No per-client deployments. No version fragmentation.
This is the "blue box" in our architecture. It is written once and shared by everyone. Inside it: the application code, the SG Engine that reads each client's rules, the template registry that stores industry templates, and the AI layer that handles document parsing and natural language input.
The isolated databases
Each client gets their own PostgreSQL database. Completely separate. Not a shared database with filters. A physically separate database.
Client A's database contains:
- Their configuration (what things they track, what states exist, what rules apply)
- Their operational data (actual orders, receipts, dispatch records)
- Their event ledger (every action that ever happened)
- Their users, roles, and permissions
Client B has the same structure but completely different content. Different configuration. Different data. Different events. Different users.
No query from Client A can ever touch Client B's database. Not through a bug. Not through a misconfigured filter. Not through a SQL injection. The databases are separate at the infrastructure level.
Why this model wins
For security: Data isolation is not a software feature. It is an infrastructure guarantee. There is no "tenant_id" to forget. There is no WHERE clause that someone omits. The databases are separate. Full stop.
For performance: Client A running a heavy report does not slow down Client B. Their queries hit different databases on potentially different servers. No noisy neighbor problem.
For customization: Each client's database contains their own SG Schema. Client A's rules are different from Client B's rules. The shared platform reads the configuration from whichever database it connects to for that request. Same engine, different rules. (How rule changes happen in minutes.)
For deployment speed: When we onboard a new client, we create a new database, load their configuration, import their data, and connect it to the shared platform. The platform already exists. The database schema already exists. We are not building a new application. We are provisioning a new isolated space.
This is one of the reasons we can deploy in days. The platform is not being rebuilt for each client. The platform is reading a new set of rules from a new database.
What this means for your data
Your data is yours. It lives in a database that only you and the SimpleGrid platform can access. No other client can see it, touch it, or affect it.
If you decide to leave, your data exports cleanly. It is in standard PostgreSQL tables. Your event ledger is a structured log. Your configuration is in readable tables. There is no proprietary format locking you in.
If you need a direct database connection for custom reporting or BI tools, that is possible. It is your database. We provide access.
The tradeoff
The honest tradeoff: isolated databases cost more to operate than a shared database. More databases means more infrastructure. More backups. More monitoring.
We accept that tradeoff because the alternative, a shared database where a single bug can expose one client's data to another, is not a tradeoff worth making for an ERP that handles operational and financial data.
Security is not a feature you bolt on. It is an architectural decision you make on day one.
SimpleGrid: one platform, isolated databases. Your data is yours. Your rules are yours. No other client can see, touch, or affect your operation.