Data & Security
Shared Databases vs. Isolated Data in Ordering Software
What makes a secure ordering portal: shared databases versus isolated data per company, encryption at rest and in transit, and questions to ask vendors.
A secure ordering portal keeps your customers' orders separate from every other company using the same software, encrypts them, and lets you take them with you. The biggest design choice behind that is whether all customers share one database or each company gets its own. Here is what the difference means for a custom manufacturer and how to ask vendors about it.
Two ways software stores many companies' data
Almost every ordering platform serves many businesses at once. Each business is a "tenant". There are two broad ways to store tenants' data.
Shared database. Every company's orders sit in the same database tables, tagged with a company ID. The software filters by that ID every time it reads or writes, so you only see your own rows.
Isolated database. Each company gets its own database. Your orders are physically separate from other companies' orders, and the software connects to the right database for your account.
Both approaches are widely used and both can be run securely. They fail in different ways, and they make some tasks easier or harder.
How the two compare
| Question | Shared database | Isolated database per company |
|---|---|---|
| What separates your data from others? | A filter in the application code | A separate database |
| Impact of a filtering bug | Could expose rows from other tenants | Limited to the one database the session is connected to |
| Exporting all your data | Needs a query that pulls only your rows | The whole database is yours |
| Deleting all your data on cancellation | Delete matching rows across many tables | Remove one database |
| Choosing where data is hosted | Harder when everyone shares one store | Easier to place one company's data in a chosen region |
| Cost to the vendor | Lower | Higher |
The second row is the one to think about. In a shared design, a single missed filter in one query can show one company's data to another. Good vendors guard against this carefully. In an isolated design, that class of mistake has a much smaller blast radius.
Why it matters for custom home products
The data in a custom ordering portal is more personal than most retail orders:
- Home addresses and delivery instructions, sometimes including gate codes or lockbox details.
- Room measurements and photos of the inside of a home.
- Dealer price tiers and credit terms that competitors would like to see.
- Saved quotes that show what a homeowner is planning to spend.
A leak of dealer pricing between two manufacturers on the same platform would be a commercial problem as well as a privacy one. That makes separation worth asking about directly.
Encryption: at rest and in transit
Separation is one layer. Encryption is another. Two terms to know:
- At rest means data stored on disk is encrypted. AES-256 is a common strong standard.
- In transit means data moving between the customer's browser, the software and other services is encrypted. TLS 1.2 or higher is the current baseline.
Ask for both, by name. "Bank-level security" on a sales page is not a standard you can check.
Card data is a separate case. It should never be stored by the ordering software at all. When card numbers go straight into the payment processor's secure fields, your portal holds no card data to protect. Our post on PCI compliance for small manufacturers explains why that matters.
Questions to ask about a secure ordering portal
Send these before you sign:
- Is our data in a shared database with other companies, or in its own database?
- What encryption is used at rest and in transit?
- Which country is our data hosted in, and can we choose?
- Who on your team can access our data, and is access logged?
- Can we export everything, at any time, without asking support?
- How many days after cancellation is our data deleted, and is that in the contract?
- Do card numbers ever reach your servers?
Questions 5 and 6 tie into ownership, which we cover in who owns your customer list. Question 3 matters for privacy assessments under Canadian law, covered in PIPEDA and Quebec Law 25.
Security is also day-to-day practice
Architecture helps, but most problems start with people and settings. Whatever software you use:
- Give each staff member and dealer their own login. Avoid shared passwords.
- Remove access the day someone leaves.
- Use approval limits so a junior team member cannot submit a large dealer order alone.
- Keep customer details out of email threads and spreadsheets where you can.
How Inlay handles this
- Each company's orders live in a separate encrypted database, with AES-256 encryption at rest and TLS 1.2 or higher in transit.
- You can choose Canadian or US hosting.
- Card numbers are entered in Stripe's secure fields and never touch Inlay's servers.
- You can export everything any time by CSV or API, and data is deleted within 30 days of cancellation.
- Dealer accounts support team logins with approval limits.
Book a 20-minute demo and ask us how your data would be stored.