Multi-Tenant срещу Single-Tenant | Избор на правилната SaaS архитектура

Всеки SaaS продукт трябва да отговори на фундаментален въпрос: как обслужвате множество клиенти от един и същ софтуер? Отговорът е вашият модел на наемане. Той влияе на разходите, сигурността, производителността и колко бързо можете да доставяте. Правилният избор в началото ви спестява болезнени миграции по-късно.

Определения

Multi-tenant

Един екземпляр на приложението обслужва всички клиенти. Всички споделят едни и същи сървъри, една и съща кодова база и често една и съща база данни. Данните на всеки клиент са логически изолирани, но инфраструктурата е споделена.

Помислете за това като за жилищна сграда. Всеки наемател живее в една и съща сграда, споделя асансьора и коридорите, но има собствен заключен апартамент с мебели.

Single-tenant

Всеки клиент получава собствен специализиран екземпляр на приложението. Отделни сървъри, отделни бази данни, понякога отделни кодови бази. Нищо не се споделя между клиентите.

Помислете за това като за самостоятелни къщи. Всеки наемател има собствена сграда, собствен ВиК, собствен двор. Пълна изолация, но по-скъпа за поддръжка.

Как работи Multi-Tenancy

Има три общи подхода към multi-tenant архитектурата, всеки с различни компромиси.

Модел 1: Споделено приложение, споделена база данни

Всички наематели споделят един екземпляр на приложението и една база данни. Данните на наемателите се разделят чрез идентификатор на наемател (обикновено колона tenant_id) във всяка таблица.

Архитектура:

• Един сървър на приложението (или клъстер) обработва всички заявки.
• Една база данни съхранява всички данни на наемателите.
• Всяка заявка включва клауза WHERE tenant_id = ? за ограничаване на данните до правилния наемател.

Предимства:

• Най-ниски разходи за инфраструктура. Една база данни, едно внедряване на приложението.
• Най-лесно за внедряване и актуализиране. Пускате веднъж, всички получават промяната.
• Лесно агрегиране на данни между наемателите за анализи и отчети.

Недостатъци:

• Най-висок риск от изтичане на данни, ако заявка забрави филтъра на наемателя.
• Един шумен наемател може да влоши производителността за всички.
• Миграциите на базата данни засягат всички наематели едновременно.
• Най-трудно съответствие с изискванията за местоположение на данните.

Това е най-често срещаният подход за B2B SaaS продукти с голям брой малки до средни клиенти.

Модел 2: Споделено приложение, отделни бази данни

Всички наематели споделят един и същ екземпляр на приложението, но всеки наемател получава собствена база данни. Приложението насочва заявките към правилната база данни въз основа на удостоверения наемател.

Архитектура:

• Един сървър на приложението (или клъстер) обработва всички заявки.
• Отделна база данни за всеки наемател.
• Маршрутизиращ слой свързва идентичността на наемателя с правилната връзка към базата данни.

Предимства:

• По-силна изолация на данните. Без риск от кръстосани заявки между наемателите.
• По-лесно изпълнение на изисквания за местоположение на данните. Можете да поставите всяка база данни в изисквания от наемателя регион.
• Архивиране и възстановяване на наемател е лесно.
• Тежкото натоварване на един наемател не заключва таблици за другите наематели.

Недостатъци:

• Повече инфраструктура за управление. Стотици наематели означават стотици бази данни.
• Миграциите на схемата трябва да се прилагат към всяка база данни поотделно.
• Отчитането между наемателите изисква заявки към множество бази данни.
• По-висока цена от напълно споделения модел.

Това е силна средна позиция за продукти, които се нуждаят от по-добра изолация без разходите на пълен single-tenancy.

Модел 3: Отделно приложение, отделна база данни

Всеки наемател получава собствен екземпляр на приложението и собствена база данни. Напълно изолирано. Това по същество е single-tenancy, но управлявано от SaaS доставчика вместо от клиента.

Архитектура:

• Специализирано внедряване на приложението за всеки наемател.
• Специализирана база данни за всеки наемател.
• Маршрутизиращ слой (често балансьор на натоварването или API gateway) насочва трафика към правилния екземпляр.

Предимства:

• Пълна изолация. Без споделени ресурси между наемателите.
• Максимална гъвкавост за персонализация на наемател.
• Производителността на един наемател никога не засяга друг.
• Най-простата история за съответствие.

Недостатъци:

• Най-високи разходи за инфраструктура.
• Сложността на внедряването расте линейно с броя на наемателите.
• Актуализациите трябва да се разгръщат към всеки екземпляр поотделно (или да се автоматизират много внимателно).
• Не се мащабира икономически за голям брой малки наематели.

Този модел има смисъл за корпоративен SaaS, където клиентите изискват специализирана инфраструктура и са готови да платят премия за нея.

Предимства и недостатъци накратко

Фактор	Multi-Tenant (Споделена БД)	Multi-Tenant (Отделна БД)	Single-Tenant
Разход за инфраструктура	Най-нисък	Среден	Най-висок
Изолация на данните	Логическа (на ниво ред)	Физическа (на ниво база данни)	Пълна
Сложност на внедряването	Ниска	Средна	Висока
Скорост на актуализации	Мигновено за всички	Мигновено приложение, миграции по БД	Разгръщане по екземпляр
Персонализация	Ограничена	Ограничена	Пълна
Съответствие	По-трудно	Умерено	Най-лесно
Мащабируемост (брой наематели)	Отлична	Добра	Слаба
Риск от шумен съсед	Висок	Среден	Никакъв

Изолация на данните и сигурност

Изолацията на данните е най-важното съображение при всеки модел на наемане. Пробив в сигурността, при който един наемател може да достъпи данните на друг наемател, е катастрофален за SaaS бизнес. Може да разруши доверието, да наруши регулации и да прекрати компанията.

Row-level security

В модел на споделена база данни, PostgreSQL Row-Level Security (RLS) е една от най-силните защити срещу изтичане на данни. RLS налага изолация на наемателите на ниво база данни, не на ниво приложение. Дори ако кодът на приложението ви има бъг, който забравя да филтрира по наемател, самата база данни предотвратява кръстосан достъп между наемателите.

Ето как да го настроите:

-- Enable RLS on a table
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Create a policy that restricts access to the current tenant
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- Force RLS even for table owners
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

Преди изпълнението на всяка заявка задайте контекста на наемателя:

-- Set at the beginning of each request/transaction
SET LOCAL app.current_tenant_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';

-- Now this query automatically returns only the current tenant's data
SELECT * FROM projects;
-- No WHERE clause needed. RLS handles it.

Изолация на ниво приложение

В допълнение към сигурността на ниво база данни, приложението ви трябва да налага граници на наемателите:

// Middleware that sets tenant context on every request
async function tenantMiddleware(req: Request, res: Response, next: NextFunction) {
  const tenantId = extractTenantId(req); // From JWT, subdomain, or header

  if (!tenantId) {
    return res.status(401).json({ error: "Tenant not identified" });
  }

  // Set tenant context for the database connection
  await db.raw(`SET LOCAL app.current_tenant_id = '${tenantId}'`);

  req.tenantId = tenantId;
  next();
}

Защитата в дълбочина е принципът тук. Никога не разчитайте на един единствен слой на изолация. Комбинирайте филтриране на ниво приложение, сигурност на ниво база данни и редовни одити за сигурност.

Съображения за производителност

Предизвикателства при споделена база данни

В споделена база данни всички наематели се конкурират за едни и същи ресурси. Наемател, който изпълнява тежък отчет, може да забави заявките за всички останали. Мерки за смекчаване:

• Пул от връзки. Използвайте PgBouncer или подобен инструмент, за да предотвратите изчерпването на връзките към базата данни от един наемател.
• Времеви ограничения за заявки. Задайте максимални времена за изпълнение, така че неконтролирана заявка да не може да заключи ресурси за неопределено време.
• Ограничаване на заявките. Наложете лимити на наемател за API заявки и операции с базата данни.
• Четящи реплики. Насочете тежки операции за четене (отчети, експортиране) към реплика, за да не засягат основната база данни.

Предимства на отделните бази данни

С бази данни на наемател, изолацията на производителността е вградена. Тежкото натоварване на един наемател засяга само неговата собствена база данни. Можете също да осигурите по-големи или по-малки бази данни въз основа на плана и използването на всеки наемател.

Компромисът е управленски разходи. Мониторирането на 500 бази данни е по-трудно от мониторирането на една. Автоматизираните инструменти стават от съществено значение.

Разходни последствия в мащаб

Нека погледнем приблизителни числа. Приемете, че имате 100 наематели.

Споделена база данни (multi-tenant):

• 1 клъстер за приложение: ~200 евро/месец
• 1 управляван PostgreSQL екземпляр: ~100 евро/месец
• Общо: ~300 евро/месец (3 евро на наемател)

Отделни бази данни (multi-tenant):

• 1 клъстер за приложение: ~200 евро/месец
• 100 малки екземпляра на бази данни: ~2 000 евро/месец
• Общо: ~2 200 евро/месец (22 евро на наемател)

Single-tenant:

• 100 екземпляра на приложението: ~5 000 евро/месец
• 100 екземпляра на бази данни: ~2 000 евро/месец
• Общо: ~7 000 евро/месец (70 евро на наемател)

Тези числа са опростени, но моделът се запазва. Споделената инфраструктура е драматично по-евтина. При 1 000 наематели разликата става още по-голяма.

Ето защо ценообразуването трябва да съответства на архитектурата. Ако таксувате 20 евро на месец и оперирате single-tenant инфраструктура на 70 евро на наемател, губите пари от всеки клиент.

Кога да изберете Multi-Tenant

Multi-tenant архитектурата е правилният избор, когато:

• Изграждате B2B SaaS за SMB. Голям обем, по-ниски ценови точки и стандартни набори от функции.
• Ефективността на разходите е важна. Трябва да поддържате ниски разходи за инфраструктура спрямо приходите.
• Искате бързи, еднакви актуализации. Внедрявате веднъж, всички наематели получават подобрението.
• Клиентите ви не изискват специализирана инфраструктура. Повечето малки и средни бизнеси не се интересуват къде живеят данните им, стига да са сигурни.
• В начални етапи сте. Започнете с multi-tenant. По-евтино е и по-просто. Винаги можете да предложите single-tenant по-късно за корпоративни клиенти.

Кога да изберете Single-Tenant

Single-tenant архитектурата има смисъл, когато:

• Продавате на корпорации. Големите организации често изискват специализирана инфраструктура като част от процеса си на доставки.
• Съответствието го изисква. Индустрии като здравеопазване (HIPAA), финанси (SOX, PCI-DSS) и правителство имат строги изисквания за изолация на данните.
• Клиентите се нуждаят от персонализация. Ако всеки клиент изисква различни конфигурации, интеграции или дори функции, single-tenant ви дава гъвкавостта.
• Ценовата ви точка го поддържа. Ако таксувате 5 000 евро или повече на месец на клиент, разходът за инфраструктура е лесно обоснован.
• Местоположението на данните е твърдо изискване. Когато данните трябва да се съхраняват в конкретна държава, отделна инфраструктура на наемател е най-директният подход.

Хибридни подходи

Не е нужно да избирате само един. Много успешни SaaS компании използват хибриден модел:

• Multi-tenant за стандартни нива. Безплатни, стартови и Pro клиенти споделят инфраструктура. Това поддържа ниски разходи и ви позволява да мащабирате.
• Single-tenant за корпоративни. Премиум клиентите получават специализирани екземпляри с персонализирани SLA, сертификати за съответствие и специализирана поддръжка.

Кодът на приложението е един и същ. Моделът на внедряване е различен. Това изисква добра автоматизация на инфраструктурата, но е доказан модел.

Как да внедрите хибриден модел

1. Изградете приложението като multi-tenant първо. Цялата логика за изолация на наемателите остава една и съща, независимо от модела на внедряване.
2. Използвайте infrastructure-as-code (Terraform, Pulumi или CDK) за автоматизиране на създаването на среди.
3. Създайте конвейер за обезпечаване, който може да стартира нова специализирана среда за минути, не за дни.
4. Поддържайте една кодова база. Същият Docker образ се изпълнява и в споделени, и в специализирани среди. Конфигурацията (не кодът) определя поведението.

Стратегии за бази данни в детайл

Базата данни е мястото, където решенията за наемане имат най-голямо въздействие. Ето три доказани стратегии.

Стратегия 1: Споделени таблици с tenant_id

Всяка таблица има колона tenant_id. Всички заявки филтрират по нея.

CREATE TABLE projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_projects_tenant ON projects(tenant_id);

-- Always query with tenant context
SELECT * FROM projects WHERE tenant_id = $1;

Най-добро за: Повечето SaaS продукти. Просто, икономично, добре разбрано.

Стратегия 2: Схема за наемател

Всеки наемател получава собствена PostgreSQL схема в споделена база данни. Таблиците имат същата структура, но данните са физически разделени.

-- Create a schema for a new tenant
CREATE SCHEMA tenant_abc123;

-- Create tables in the tenant's schema
CREATE TABLE tenant_abc123.projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Set the search path per request
SET search_path TO tenant_abc123, public;

-- Now queries are automatically scoped
SELECT * FROM projects;

Най-добро за: Продукти, които се нуждаят от по-силна изолация от ниво ред, но не искат разходите на отделни бази данни. Работи добре до няколкостотин наематели.

Стратегия 3: Отделни бази данни

Всеки наемател получава специализиран PostgreSQL екземпляр (или специализирана база данни на споделен сървър).

// Database connection routing
class TenantDatabaseRouter {
  private connections: Map<string, DatabasePool> = new Map();

  async getConnection(tenantId: string): Promise<DatabasePool> {
    if (this.connections.has(tenantId)) {
      return this.connections.get(tenantId)!;
    }

    const config = await this.loadTenantDbConfig(tenantId);
    const pool = new DatabasePool({
      host: config.host,
      port: config.port,
      database: config.database,
      user: config.user,
      password: config.password,
    });

    this.connections.set(tenantId, pool);
    return pool;
  }

  private async loadTenantDbConfig(tenantId: string): Promise<DbConfig> {
    // Look up tenant's database connection details
    // from a central configuration store
    return await configStore.get(`tenants/${tenantId}/database`);
  }
}

Най-добро за: Корпоративен SaaS с високостойностни клиенти, строги изисквания за съответствие или задължения за местоположение на данните.

Вземане на решение

Ето проста рамка за решение:

1. Какъв е размерът на целевия ви клиент? SMB сочи към multi-tenant. Корпорации сочат към single-tenant или хибрид.
2. Каква е ценовата ви точка? Под 100 евро/месец, имате нужда от multi-tenant за рентабилност. Над 1 000 евро/месец, single-tenant става жизнеспособен.
3. Какви са изискванията за съответствие? Регулираните индустрии често изискват по-силна изолация.
4. Колко наематели очаквате? Стотици или хиляди наематели се нуждаят от споделена инфраструктура. Десет до петдесет големи наематели могат да работят със специализирани екземпляри.
5. Какъв е оперативният капацитет на екипа ви? Single-tenant изисква повече DevOps инвестиция. Multi-tenant е оперативно по-прост.

Ако не сте сигурни, започнете с multi-tenant със споделена база данни и row-level security. Това е най-евтината опция, сигурна е при правилна реализация и поддържа архитектурата ви проста. Винаги можете да добавите специализирано ниво за корпоративни клиенти по-късно.

Заключение

Няма универсално правилен модел на наемане. Правилният избор зависи от клиентите ви, ценообразуването ви, изискванията за съответствие и оперативните ви възможности.

Повечето SaaS продукти трябва да започнат с multi-tenant. По-евтино е, по-просто е и се мащабира добре. Когато се придвижите нагоре по пазара и започнете да продавате на по-големи организации, добавете single-tenant опции за клиенти, които се нуждаят от тях и ще платят съответно.

Архитектурата трябва да обслужва бизнеса, не обратното. Изграждайте за клиентите, които имате днес, и проектирайте с достатъчно гъвкавост, за да обслужвате клиентите, които искате утре.

---

Нуждаете се от помощ при избора на правилната архитектура за вашия SaaS продукт? Изграждали сме multi-tenant и single-tenant системи в различни индустрии. Нека определим най-добрия подход за вашия проект.