Every SaaS product starts with the same question: should each customer get their own database, or should everyone share one? The pooled model answers with the simplest possible architecture — one database, one set of tables, all tenants mixed together. A tenant_id column on every row is the only thing separating Customer A's data from Customer B's.

How It Works

Every table includes a tenant_id column:

1CREATE TABLE orders (
2  id         BIGSERIAL PRIMARY KEY,
3  tenant_id  UUID NOT NULL,
4  user_id    BIGINT NOT NULL,
5  total      DECIMAL(10,2),
6  created_at TIMESTAMPTZ DEFAULT now()
7);
8
9CREATE INDEX idx_orders_tenant ON orders(tenant_id);

Every query must filter by tenant_id. A missing WHERE clause means one tenant sees another tenant's data — the worst possible bug in SaaS. The application layer adds this filter to every SELECT, UPDATE, and DELETE.

Row-Level Security (RLS)

Relying on application code to always include tenant_id is fragile. A single missed WHERE clause is a data breach. Row-Level Security pushes the enforcement into the database itself:

1ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
2
3CREATE POLICY tenant_isolation ON orders
4  USING (tenant_id = current_setting('app.current_tenant')::UUID);

With RLS enabled, the database silently appends the tenant filter to every query. Even if application code forgets the WHERE clause, the database returns only the current tenant's rows. This is defense-in-depth — the application should still filter by tenant_id for query planning, but RLS catches the mistakes.

The setup flow: the application sets SET app.current_tenant = '<tenant-uuid>' at the start of each request (typically in middleware), and RLS policies reference this session variable. Every subsequent query in that connection is scoped to that tenant automatically.

Connection Pool Configuration

All tenants share a single connection pool. The pool size must accommodate the total concurrent query load across all tenants, not just one:

Pool size = (number of CPU cores * 2) + effective_spindle_count
Example: 8-core server → pool size of 20 connections

With 500 tenants sharing 20 connections, each tenant averages 0.04 connections — but traffic is bursty. A spike from one tenant can exhaust the pool, blocking all tenants. Connection timeout settings and per-tenant query quotas prevent monopolization. PgBouncer in front of PostgreSQL enables thousands of application connections to multiplex across a smaller pool of database connections.

Table Partitioning by Tenant

For very large tables, PostgreSQL's declarative partitioning by tenant_id can improve query performance and maintenance:

1CREATE TABLE orders (
2  id         BIGSERIAL,
3  tenant_id  UUID NOT NULL,
4  total      DECIMAL(10,2),
5  created_at TIMESTAMPTZ
6) PARTITION BY HASH (tenant_id);
7
8CREATE TABLE orders_p0 PARTITION OF orders
9  FOR VALUES WITH (MODULUS 16, REMAINDER 0);
10-- ... create partitions p1 through p15

Hash partitioning distributes tenants across a fixed number of partitions. When a query includes WHERE tenant_id = X, the planner prunes to a single partition — scanning 1/16th of the data instead of the full table. This also makes tenant deletion faster (drop a partition vs. delete millions of rows) and enables parallel maintenance (vacuum one partition at a time).

Why Teams Start Here

Cost efficiency. One database means one instance to provision, monitor, and back up. CPU, RAM, and IOPS are shared across all tenants, keeping per-tenant cost near zero. A startup with 100 tenants pays for one database, not 100.

Simple operations. Schema migrations run once. Index changes apply to everyone. A single connection pool serves all tenants. There is no per-tenant provisioning automation to build or maintain.

Fast onboarding. Adding a new tenant is an INSERT into a tenants table. No infrastructure changes, no new database instances, no DNS entries. Self-serve signup works naturally.

Cross-tenant analytics. Aggregate queries across all tenants are trivial — the data is already in one place. Platform-level dashboards, usage reports, and billing aggregation require no cross-database joins.

The Risks

Noisy neighbor. A single tenant running expensive queries degrades performance for everyone. One tenant's full-table scan locks pages that other tenants need. Without resource isolation, a runaway query from Tenant A slows down Tenant B's checkout flow.

Blast radius. A schema migration bug, a corrupted index, or a database crash affects every tenant simultaneously. There is no way to isolate the blast radius — if the database is down, every tenant is down.

Compliance friction. Some regulations (GDPR, HIPAA, data residency laws) require data isolation or geographic separation. A shared database makes it difficult to prove that Tenant A's data is physically separate from Tenant B's. Auditors may not accept RLS as sufficient isolation.

Scaling ceiling. As tenant count and data volume grow, the single database becomes a bottleneck. Vertical scaling (bigger machine) has limits. Horizontal scaling (sharding by tenant_id) adds complexity that erodes the simplicity advantage.

Indexing Strategy

Every frequently queried table needs a composite index with tenant_id as the leading column:

1CREATE INDEX idx_orders_tenant_created
2  ON orders(tenant_id, created_at DESC);
3
4CREATE INDEX idx_orders_tenant_status
5  ON orders(tenant_id, status);

Without tenant_id as the leading column, the database scans the entire index before filtering by tenant — effectively a full index scan for every query. With tenant_id first, the database jumps directly to one tenant's rows, then uses the second column for ordering or filtering. The difference between a 50ms query and a 500ms query at scale.

Monitoring and Tenant-Aware Metrics

Standard database metrics (CPU, memory, query latency) do not tell you which tenant is causing problems. Add tenant-aware instrumentation:

1-- Find the noisiest tenants by query count
2SELECT tenant_id, count(*) as query_count,
3       avg(duration_ms) as avg_latency
4FROM query_log
5WHERE timestamp > now() - interval '1 hour'
6GROUP BY tenant_id
7ORDER BY query_count DESC
8LIMIT 10;

Track per-tenant metrics: query count, average latency, rows scanned, and storage consumed. When a tenant's query count spikes 10x, you can throttle them or route their traffic to a read replica before they degrade performance for everyone else.

The schema-per-tenant model keeps all tenants in one database instance but gives each tenant its own schema (namespace). Tenant A's tables live in schema_tenant_a, Tenant B's in schema_tenant_b. The tables have identical structures but the data is completely separated — no tenant_id column needed because the schema boundary provides isolation.

How It Works

Each tenant gets a dedicated schema at signup:

1CREATE SCHEMA tenant_acme;
2
3CREATE TABLE tenant_acme.orders (
4  id         BIGSERIAL PRIMARY KEY,
5  user_id    BIGINT NOT NULL,
6  total      DECIMAL(10,2),
7  created_at TIMESTAMPTZ DEFAULT now()
8);

The application sets the search path at the start of each request:

SET search_path TO tenant_acme, public;

After this, all unqualified table references resolve to the tenant's schema. SELECT * FROM orders reads from tenant_acme.orders without any tenant_id filter. The schema boundary replaces the WHERE clause.

Onboarding a new tenant means running the schema creation script — creating the schema, all tables, indexes, and seed data. This is more work than inserting a row (pooled model) but far less than provisioning a new database instance (database-per-tenant model).

A typical onboarding script:

1-- 1. Create the schema
2CREATE SCHEMA tenant_acme;
3
4-- 2. Clone tables from a template schema
5-- (use pg_dump of template_schema | sed + psql)
6
7-- 3. Seed reference data
8INSERT INTO tenant_acme.config (key, value)
9VALUES ('plan', 'professional'), ('created_at', now());
10
11-- 4. Register in tenant catalog
12INSERT INTO public.tenant_catalog (tenant_id, schema_name, tier)
13VALUES ('acme', 'tenant_acme', 'professional');

This process takes seconds and can be fully automated. Most teams maintain a "template schema" with the latest table definitions and clone it for each new tenant.

Advantages Over Pooled

Stronger isolation without separate infrastructure. A missing WHERE clause cannot leak data across tenants because the search path limits visibility to one schema. Tenant A's queries physically cannot access Tenant B's tables.

Per-tenant customization. Each schema can have slightly different indexes, additional columns, or even extra tables for specific tenants. An enterprise customer that needs a custom reporting table gets it in their schema without affecting anyone else.

Easier per-tenant backup and restore. You can pg_dump a single schema to back up one tenant's data. Restoring a single tenant does not require restoring the entire database. This is valuable when a tenant accidentally deletes data and needs a point-in-time recovery.

Example per-tenant backup:

1# Back up single tenant
2pg_dump --schema=tenant_acme mydb > tenant_acme_backup.sql
3
4# Restore single tenant (drop and recreate)
5psql mydb -c "DROP SCHEMA tenant_acme CASCADE;"
6psql mydb < tenant_acme_backup.sql

In the pooled model, restoring one tenant's data from a database backup means restoring the entire database to a separate instance, extracting that tenant's rows, and merging them back — a multi-hour process that risks overwriting other tenants' changes.

Cleaner data management. Deleting a tenant is DROP SCHEMA tenant_acme CASCADE — fast and complete. In the pooled model, deleting a tenant means running DELETE across every table with a WHERE clause, which is slower, generates more WAL, and risks leaving orphaned rows. Schema-level deletion also satisfies data erasure requirements under GDPR's "right to be forgotten" more convincingly than row-level deletion, because the entire namespace is removed rather than individual records that might have been missed.

Per-tenant storage monitoring. You can track each tenant's disk usage independently by querying schema-level statistics. This enables usage-based billing and proactive capacity planning — identify tenants approaching storage limits before they hit them.

The Costs

Schema migration complexity. A column change must be applied to every tenant's schema individually. With 500 tenants, ALTER TABLE orders ADD COLUMN discount DECIMAL runs 500 times. Migrations must be scripted to iterate over all schemas, handle partial failures (what if migration succeeds for 300 schemas and fails for the 301st?), and ideally run in parallel to avoid hour-long migration windows.

Connection overhead. Each tenant's schema still shares the same database connection pool, but the application must switch search paths per request. Connection poolers like PgBouncer require careful configuration — in transaction-level pooling mode, SET search_path must be issued inside each transaction because connections are shared across tenants between transactions.

Metadata bloat. Each schema creates its own set of system catalog entries (pg_class, pg_attribute, pg_index). With 1,000 tenants and 50 tables each, the system catalog holds 50,000 table entries. PostgreSQL's query planner reads these catalogs on every query, and bloated catalogs slow down planning. At around 5,000-10,000 schemas, this overhead becomes noticeable.

No resource isolation. Like the pooled model, all tenants share CPU, memory, and I/O. The noisy neighbor problem still exists. Schema separation is a logical boundary, not a physical one. A heavy query in schema_tenant_a still saturates the same buffer pool that schema_tenant_b depends on.

Migration Automation

Manual migrations across hundreds of schemas are error-prone. Build a migration runner that:

1. Iterates over all tenant schemas from a registry table
2. Runs the migration within a transaction per schema
3. Records success or failure in a schema_migrations metadata table
4. Supports retry for failed schemas without re-running successful ones
5. Runs in parallel batches (10-50 schemas at a time) to reduce total migration time

Example migration tracking:

1CREATE TABLE public.schema_migration_status (
2  schema_name  TEXT,
3  migration_id TEXT,
4  status       TEXT,  -- 'pending', 'success', 'failed'
5  applied_at   TIMESTAMPTZ,
6  error_msg    TEXT,
7  PRIMARY KEY (schema_name, migration_id)
8);

The runner queries for schemas where a given migration is not yet 'success' and processes them. This makes migrations idempotent and resumable — the runner can be restarted at any point without double-applying.

The database-per-tenant model gives each tenant their own database instance — completely separate processes, separate storage, separate everything. This is maximum isolation at maximum cost. Each tenant's data lives in its own world, untouchable by any other tenant's queries, migrations, or failures.

How It Works

When a new tenant signs up, the platform provisions a new database instance (or a new database within a managed cluster). A tenant catalog (routing table) maps each tenant to its database connection string:

tenant_acme  → postgres://db-acme.internal:5432/app
tenant_globex → postgres://db-globex.internal:5432/app
tenant_initech → postgres://db-initech.internal:5432/app

The application's routing layer reads the tenant identifier from the request (subdomain, JWT claim, or API key), looks up the connection string, and routes the query to the correct database. Each database has its own connection pool, its own storage, and its own resource allocation.

The routing layer is typically implemented as middleware:

1def tenant_middleware(request):
2    tenant_id = extract_tenant(request)  # from JWT or subdomain
3    conn_string = catalog.lookup(tenant_id)  # cached in Redis
4    request.db = get_connection(conn_string)
5    return next(request)

Every downstream handler uses request.db without knowing whether it connects to a shared database or a dedicated instance. This abstraction is what makes the database-per-tenant model compatible with a hybrid architecture later.

Why Teams Choose This

Complete resource isolation. Tenant A's heavy report query cannot affect Tenant B's checkout flow. Each database has its own CPU, memory, and I/O allocation. The noisy neighbor problem is eliminated by design.

Independent scaling. A tenant that outgrows their database gets a bigger instance — without affecting anyone else. A tenant with minimal usage stays on a small instance. You pay proportionally to each tenant's actual resource consumption. This is especially valuable for tenants with unpredictable traffic patterns — an e-commerce tenant with Black Friday spikes can be scaled up temporarily without affecting other tenants' costs.

Custom SLAs. Different tenants can have different uptime guarantees backed by different infrastructure configurations. An enterprise tenant gets a multi-AZ database with synchronous replication (99.99% uptime). A startup tenant gets a single-AZ instance (99.9% uptime) at a lower price point.

Simplified compliance. Data residency requirements are trivial — provision the tenant's database in the required region. HIPAA, SOC 2, and PCI auditors can verify isolation by inspecting the infrastructure. There is no argument about whether RLS is sufficient because the data is physically separate.

Per-tenant maintenance. Schema migrations can be rolled out gradually — migrate Tenant A, verify, then migrate Tenant B. A migration bug affects one tenant, not all of them. Database version upgrades, backup schedules, and maintenance windows can be customized per tenant. This enables canary deployments at the data layer — roll out a schema change to 5% of tenants, monitor for errors, then proceed to the rest.

Clean tenant offboarding. Deleting a tenant means dropping a database and decommissioning the instance. No row-level cleanup, no orphaned data, no cascade logic.

Managed Database Services

Cloud-managed databases (AWS RDS, Google Cloud SQL, Azure Database) significantly reduce the operational burden of database-per-tenant. Provisioning a new instance is an API call, not a hardware procurement process. Automated backups, patch management, and failover come built-in.

The cost structure shifts from capital expenditure (buying servers) to operational expenditure (per-hour billing). This makes database-per-tenant feasible for mid-market SaaS that would not have the ops team to manage bare-metal instances. A managed PostgreSQL instance on AWS RDS starts at roughly $15/month (db.t3.micro), making the per-tenant cost low enough for mid-tier subscriptions.

However, managed services have limits. Each cloud provider caps the number of database instances per account (typically 40-100 without requesting an increase). Aurora Serverless v2 can scale to zero when idle, which reduces cost for low-traffic tenants, but cold-start latency (5-10 seconds for the first query after idle) must be acceptable for the use case.

The Costs

Infrastructure overhead. Each database instance has a fixed baseline cost regardless of usage — the database process consumes memory, the storage has a minimum allocation, monitoring agents run per instance. With 1,000 tenants, you operate 1,000 database instances. At $50/month per small instance, that is $50,000/month in database costs before any tenant generates revenue.

Operational complexity. Schema migrations must be orchestrated across hundreds or thousands of databases. Monitoring requires aggregating metrics from every instance. Alerting must distinguish between "one tenant's database is slow" and "a systemic problem affects all databases." The operations team needs robust automation — manual management is impossible beyond a few dozen tenants.

Cross-tenant queries are impossible. A platform-wide analytics dashboard ("total revenue across all tenants") cannot be answered by a single SQL query. You need an ETL pipeline that extracts data from every tenant database into a central analytics warehouse. This adds latency, complexity, and another system to maintain. Common approaches include CDC streams into a shared analytics warehouse, or periodic batch exports. Either way, the analytics data is eventually consistent — typically hours behind, not real-time.

Connection management. Each tenant database needs its own connection pool. With 1,000 tenants, the application layer manages 1,000 connection pools. Connection poolers like PgBouncer must be deployed per tenant or configured to multiplex across databases. The application's memory footprint grows linearly with tenant count.

Automation Requirements

Database-per-tenant is only viable with infrastructure-as-code automation. At minimum, you need:

Provisioning pipeline — When a new tenant signs up, automation creates a new database instance, applies the schema, runs seed data, registers the connection string in the tenant catalog, and configures monitoring and alerting. This must complete in under 2 minutes for acceptable signup experience.

Migration orchestrator — A tool that connects to every tenant database, runs the migration, and reports per-tenant status. Terraform, Ansible, or a custom orchestrator can parallelize across databases. The orchestrator must handle partial failures gracefully — 999 of 1,000 databases migrated successfully, and the runner retries the 1 that failed.

Monitoring aggregation — Each tenant database emits metrics independently. A centralized monitoring system (Datadog, Prometheus with federation) aggregates these into both per-tenant dashboards ("is Tenant Acme's database healthy?") and fleet-wide dashboards ("which tenant databases have elevated query latency?").

Automated scaling — Monitor each tenant's resource utilization and automatically resize instances that are consistently over- or under-provisioned. A tenant using 5% of their allocated CPU should be downscaled. A tenant hitting 90% CPU needs an upgrade before performance degrades. Cloud providers offer auto-scaling for managed databases (Aurora auto-scaling, Azure Hyperscale), which can handle this automatically at the cost of less predictable billing.

Without this automation, the operations team scales linearly with tenant count. Every new tenant adds monitoring burden, migration work, and incident response scope. The break-even point is typically around 50-100 tenants — below that, manual management is feasible; above that, automation is mandatory.

Real-world SaaS products rarely fit cleanly into one model. A startup begins with the pooled model for cost efficiency, then discovers that their largest customer demands dedicated infrastructure. A healthcare SaaS needs HIPAA-compliant isolation for hospital tenants but can use shared infrastructure for clinic tenants. The hybrid model handles these realities by running multiple isolation levels simultaneously.

The Tiered Architecture

A tenant catalog service sits in front of all databases and routes requests based on the tenant's tier:

Free and standard tiers use the pooled model. Hundreds or thousands of tenants share one database with RLS isolation. Per-tenant cost approaches zero. Onboarding is instant (insert a row).

Professional tier uses schema-per-tenant. Tenants that need stronger data isolation or per-tenant customization get their own schema within a shared database instance. Moderate cost, moderate isolation.

Enterprise tier uses database-per-tenant. High-value tenants get dedicated database instances with full resource isolation, custom backup schedules, and data residency guarantees. High cost, maximum isolation.

Tenant Promotion (Moving Up Tiers)

The hardest part of the hybrid model is promotion — moving a tenant from pooled to schema-per-tenant, or from schema-per-tenant to database-per-tenant. This is a live data migration while the tenant continues using the product.

The migration flow:

1. Provision the target (new schema or new database instance)
2. Copy existing data from the source to the target using logical replication or ETL
3. Enable dual-write — new writes go to both source and target
4. Verify data consistency between source and target
5. Switch the tenant catalog entry to point to the new target
6. Clean up the source (delete rows from pooled tables or drop the old schema)

Steps 2-5 must happen with minimal downtime. The dual-write phase catches any data written during the copy phase. The catalog switch is atomic — one moment the tenant reads from the old location, the next moment from the new location. A brief maintenance window (seconds to minutes) during the switch is typical.

Data Consistency During Promotion

The trickiest part of promotion is ensuring no data is lost or duplicated. Consider this scenario: during the copy phase, a customer places an order. The order is written to the pooled database (the current source of truth). The copy process may or may not have already passed the orders table. Three approaches handle this:

Change Data Capture (CDC) — Tools like Debezium read the database's write-ahead log and stream every change to the target. The CDC stream captures any writes made during the copy, regardless of timing. This is the most reliable approach but requires WAL-level access.

Application-level dual-write — The application writes to both source and target simultaneously. This guarantees both databases have every write, but introduces complexity: if the write to the target fails, do you roll back the source write? Most implementations write to the source first (the current primary) and async-replicate to the target, tolerating brief inconsistency.

Snapshot + replay — Take a consistent snapshot of the tenant's data, restore it to the target, then replay the WAL from the snapshot point forward. This is a database-native approach (PostgreSQL's pg_dump + pg_restore + logical replication from the snapshot LSN) that avoids application-level changes.

Regardless of approach, always verify data consistency before switching. A simple verification:

1-- On source (pooled DB)
2SELECT count(*), max(updated_at) FROM orders
3WHERE tenant_id = 'acme';
4
5-- On target (dedicated DB)
6SELECT count(*), max(updated_at) FROM orders;
7
8-- Counts and timestamps must match

If they do not match, extend the dual-write phase and investigate. Never switch the catalog entry until consistency is confirmed.

Tenant Demotion (Moving Down)

Demotion is the reverse — moving a tenant from dedicated to shared infrastructure, typically when they downgrade their subscription. This is operationally simpler because moving data into a pooled database just means inserting rows with a tenant_id. The risk is that the pooled database may have schema differences (the dedicated database may have custom columns or tables that do not exist in the pooled schema).

Best practice: maintain schema compatibility across all tiers. The pooled, schema-per-tenant, and database-per-tenant databases should all have the same table definitions. Enterprise-specific features should use a generic extension mechanism (a JSON column, a key-value settings table) rather than custom columns. This makes both promotion and demotion safe because the data model is consistent regardless of tier.

The Tenant Catalog

The tenant catalog is the single source of truth for "where does this tenant's data live?" It maps tenant identifiers to connection strings, schema names, and tier levels:

1tenant_id  | tier        | connection_string                      | schema
2acme       | enterprise  | postgres://db-acme.internal:5432/app   | public
3globex     | professional| postgres://shared-pro.internal:5432/app| tenant_globex
4initech    | free        | postgres://shared-free.internal:5432/app| public

This catalog is cached aggressively (Redis with TTL) because every request reads it. Cache invalidation happens on tier changes or infrastructure updates. The catalog itself lives in a highly available metadata database separate from any tenant database.

Observability Across Tiers

Monitoring a hybrid system is harder than monitoring a single-model system because metrics come from different sources:

• Pooled tier: standard database metrics (CPU, connections, query latency) plus per-tenant breakdowns from application-level instrumentation
• Schema-per-tenant tier: same database-level metrics, but per-schema storage and query stats available from pg_stat_user_tables filtered by schema
• Database-per-tenant tier: independent metrics per instance, aggregated by a fleet-level monitoring dashboard

A unified alerting system must normalize these different metric sources into consistent tenant-level SLAs. "Tenant X's p99 query latency is above 200ms" should work regardless of which tier the tenant occupies. This requires a metadata layer that maps alert sources to tenant identifiers and tier levels.

The right model depends on four variables: tenant count, revenue per tenant, isolation requirements, and operational team size. No model is universally best — each is a trade-off between cost, isolation, and operational complexity.

Decision Framework

Start pooled when you have many tenants with low revenue per tenant, no strict compliance requirements, and a small engineering team. The pooled model has the lowest operational cost and the fastest time to market. Most SaaS startups should start here and only move to other models when a concrete problem forces the change.

Move to schema-per-tenant when you need per-tenant data isolation without the cost of separate databases. This fits mid-market SaaS where tenants expect data separation (for audits or contractual reasons) but do not need resource isolation. The schema boundary provides stronger guarantees than RLS while sharing infrastructure costs.

Move to database-per-tenant when tenants require complete resource isolation, data residency in specific regions, or independent scaling. This fits enterprise SaaS with fewer tenants at higher price points. The per-tenant cost must be absorbable by the tenant's subscription revenue.

Use hybrid when you serve multiple market segments with different isolation needs. A free tier on pooled, a professional tier on schema-per-tenant, and an enterprise tier on database-per-tenant. This is the most complex to operate but serves the widest range of customers.

Common Mistakes

Over-isolating too early. A startup with 20 tenants does not need database-per-tenant. The operational complexity of managing 20 database instances, running migrations across all of them, and monitoring each one individually will slow down the team more than the noisy neighbor problem ever would at that scale.

Under-isolating under pressure. A pooled model with 500 tenants and no RLS is a data breach waiting to happen. If you choose the pooled model, RLS is non-negotiable. Every month without RLS is a month where a single missing WHERE clause could expose every tenant's data.

Ignoring the migration path. Choosing a model without planning how to migrate to a different model later creates technical debt. Design the tenant routing layer from day one — even if every tenant points to the same database today. When you need to promote a tenant, the routing layer is already in place.

Matching isolation to compliance, not preference. A tenant saying "we want our own database" is different from a regulation requiring it. Understand the actual compliance requirement before adding infrastructure complexity. Often, schema-per-tenant with encryption at rest satisfies the requirement without the cost of dedicated databases.

Not building the routing layer early. Build the tenant routing layer from day one, even in the pooled model. Every request should resolve the tenant, look up the catalog, and get a connection — even if the catalog maps every tenant to the same database. When you need to promote a tenant to dedicated infrastructure, you change one catalog entry instead of refactoring the entire data access layer.