Self-Hosting Umami Analytics on Linux VPS in Pakistan: The Lightweight Google Analytics 4 Alternative

Pakistani digital publishers, high-volume e-commerce storefronts, software agencies, and independent webmasters are confronting a structural breakdown with mainstream web analytics. For more than two decades, Google Analytics served as the default tracking infrastructure for commercial websites. However, the migration to Google Analytics 4 (GA4) introduced systemic architectural compromises: intrusive data thresholding, 24-to-48-hour reporting latency, opaque interface ergonomics, and heavy clientside JavaScript that degrades Core Web Vitals.

For Pakistani businesses operating in competitive digital environments, GA4 presents four critical bottlenecks:

1. Ad-Blocker Blindness: Browser extensions such as uBlock Origin, Brave Shields, and DNS sinkholes (AdGuard, NextDNS) aggressively block requests to google-analytics.com and googletagmanager.com. In tech, e-commerce, and digital media demographics across Pakistan, 25% to 45% of visitor traffic is entirely invisible to GA4, distorting attribution and conversion reporting.
2. Core Web Vitals Degradation: The standard Google Tag Manager (gtm.js) and Google Analytics (gtag.js) payload introduces between 45 KB and 120 KB of uncompressed JavaScript. Its parsing and execution monopolize the browser’s main thread during the critical page-load lifecycle, degrading Interaction to Next Paint (INP) and Total Blocking Time (TBT).
3. Data Thresholding and Attribution Latency: GA4 utilizes algorithmic sampling and identity modeling that hides detailed granular traffic sources for low-to-medium volume segments. Furthermore, the standard 24-to-48-hour processing window paralyzes Pakistani publishers covering breaking news and e-commerce operators monitoring time-sensitive flash sales (such as Blessed Friday or Ramadan campaigns).
4. Foreign Currency Overhead and Compliance: Commercial hosted privacy analytics platforms (such as Fathom, Simple Analytics, or Plausible Cloud) mandate recurring subscription payments in US Dollars. Pakistani entities face international card restrictions, State Bank of Pakistan (SBP) foreign exchange filing requirements, and substantial advance withholding taxes under Section 236Y/F of the Income Tax Ordinance.

Umami Analytics provides an enterprise-grade, open-source solution. Built on Next.js, Prisma, and PostgreSQL, Umami delivers real-time, cookieless, GDPR- and PECR-compliant web analytics. Its client tracking script is under 3 KB gzipped, and the entire platform can be self-hosted on a private server for negligible operating expenses.

This guide provides an end-to-end production manual for deploying, hardening, proxying, and scaling Umami Analytics on an enterprise-grade Linux Cloud VPS in Pakistan.

---

1. Architectural Overview: How Umami Operates

Umami replaces cumbersome clientside tag managers with a clean, high-throughput micro-architecture designed to ingest telemetry data asynchronously and store it directly in relational tables.

+-----------------------------------------------------------------------------------+
|                        UMAMI ANALYTICS SYSTEM TOPOLOGY                            |
+-----------------------------------------------------------------------------------+
                                          |
                              [ Client Browser / App ]
                      Executes lightweight tracker (<3 KB)
                                          |
                                    HTTPS Port 443
                                          |
                             [ Reverse Proxy Engine ]
                                 (Caddy 2 / Nginx)
                     Terminates TLS / Masks Tracking Endpoints
                                          |
                       Internal Bridge: localhost:3000
                                          |
                         [ Umami Next.js Application ]
                     Worker threads parse payload & session
                                          |
                        Prisma Client Connection Pool
                                          |
                          [ PostgreSQL 16 Database ]
               Partitioned `website_event` & `session` tables
                                          |
                     [ Persistent NVMe Storage Subsystem ]

Core Components

• The Tracking Engine (script.js): A custom, pure JavaScript telemetry script weighing less than 3 KB. It automatically tracks pageviews, referrer strings, screen dimensions, browser operating systems, device types, and geographic location without writing cookies, setting persistent browser storage keys, or gathering Personally Identifiable Information (PII).
• The Application Layer (Next.js & Prisma): Umami utilizes Next.js for its administrative interface and data collection APIs (/api/send). Incoming HTTP POST payloads are validated, anonymized via a cryptographic daily salt, and routed into a connection-pooled Prisma ORM layer.
• Relational Storage Engine (PostgreSQL): Telemetry data is recorded in relational schema tables—primarily session and website_event. This relational approach allows direct SQL querying, custom Business Intelligence (BI) integration, automated table partitioning, and complete data ownership.

---

2. Infrastructure Sizing and VPS Prerequisites

Telemetry ingestion is write-intensive. While read queries (dashboard views) occur intermittently, write queries (incoming hits) scale linearly with website traffic. Selecting an appropriately configured host is essential to avoid dropped metrics and database lockups.

Recommended Resource Allocation

Monthly Pageviews	Concurrent Traffic	Recommended Configuration	Storage Target	Target Hosting Tier
Up to 500,000	50 - 150 concurrent	2 vCPU, 4 GB RAM	40 GB NVMe	Entry Linux VPS
500,000 - 3,000,000	150 - 600 concurrent	4 vCPU, 8 GB RAM	100 GB NVMe	High-Memory Cloud VPS
3,000,000 - 15,000,000	600 - 2,500 concurrent	8 vCPU, 16 GB RAM	250 GB NVMe	Performance Cloud VPS
15,000,000+	2,500+ concurrent	16+ Cores, 64 GB RAM	Enterprise NVMe RAID	Dedicated Bare Metal

Host Initialization on Ubuntu 24.04 LTS

Connect to your server via SSH and update the core distribution packages:

# Update repository indexes and upgrade packages
sudo apt update && sudo apt upgrade -y

# Install essential dependencies
sudo apt install -y curl wget git ufw htop fail2ban ca-certificates gnupg lsb-release

Configure the local Uncomplicated Firewall (UFW) to enforce strict network isolation:

# Set baseline security policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Permit SSH, HTTP, and HTTPS
sudo ufw allow 22/tcp comment 'SSH Management'
sudo ufw allow 80/tcp comment 'HTTP ACME Challenge'
sudo ufw allow 443/tcp comment 'HTTPS Encrypted Web'

# Activate firewall
sudo ufw --force enable
sudo ufw status verbose

Install the official Docker Engine and the Docker Compose plugin:

# Add Docker official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Register Docker repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install Docker packages
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Enable and start Docker daemon
sudo systemctl enable --now docker

---

3. Production Deployment via Docker Compose

To ensure security and operational isolation, run Umami within a private, non-root Docker network backed by an optimized PostgreSQL instance.

Project Directory Structure

Create a structured filesystem hierarchy inside /opt:

sudo mkdir -p /opt/umami/data
cd /opt/umami

Environment Configuration (.env)

Generate a robust application secret and secure database credentials. Use openssl to generate cryptographically random strings:

# Generate a 32-character random string for APP_SECRET
openssl rand -hex 32

Create /opt/umami/.env:

# Umami Environment Configuration
# /opt/umami/.env

# Application Secret Salt (Replace with generated string)
APP_SECRET=a8f5b493c1209e864d37c92b5e114fa8d26c91e038475a6c8b9123d45ef67890

# PostgreSQL Production Credentials
POSTGRES_DB=umami_db
POSTGRES_USER=umami_user
POSTGRES_PASSWORD=SuperSecureProductionDbPassword2026!

# Database Connection URI for Prisma
DATABASE_URL=postgresql://umami_user:SuperSecureProductionDbPassword2026!@umami-db:5432/umami_db

# Umami Runtime Configuration
PORT=3000
NODE_ENV=production
DISABLE_TELEMETRY=1
CLIENT_IP_HEADER=x-forwarded-for

Production Docker Compose Specification

Create /opt/umami/docker-compose.yml:

services:
  umami-db:
    image: postgres:16-alpine
    container_name: umami-db
    restart: always
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - /opt/umami/data:/var/lib/postgresql/data
    networks:
      - umami-internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5
    deploy:
      resources:
        limits:
          memory: 4096M
        reservations:
          memory: 1024M

  umami-app:
    image: ghcr.io/umami-software/umami:postgresql-latest
    container_name: umami-app
    restart: always
    environment:
      DATABASE_URL: ${DATABASE_URL}
      APP_SECRET: ${APP_SECRET}
      PORT: 3000
      CLIENT_IP_HEADER: ${CLIENT_IP_HEADER}
      DISABLE_TELEMETRY: ${DISABLE_TELEMETRY}
    ports:
      - "127.0.0.1:3000:3000"
    networks:
      - umami-internal
    depends_on:
      umami-db:
        condition: service_healthy
    deploy:
      resources:
        limits:
          memory: 2048M
        reservations:
          memory: 512M

networks:
  umami-internal:
    driver: bridge

Launch the stack in detached mode:

docker compose up -d

Verify service operation and inspect health status:

docker compose ps
docker compose logs -f umami-app

Once running, Umami initializes database schemas through Prisma migrations and binds to internal interface 127.0.0.1:3000.

---

4. Defeating Ad Blockers: Implementing a First-Party Tracking Proxy

The single greatest operational advantage of self-hosting Umami is eliminating tracking blindness caused by uBlock Origin, Brave Shields, and DNS sinkholes.

Modern content blockers match network requests against maintained blacklists such as EasyList and EasyPrivacy. If your tracking script is delivered from a domain containing words like analytics, metrics, telemetry, or paths like /script.js and /api/send, the request is dropped client-side.

To achieve 99%+ telemetry capture, proxy the tracking assets through your website’s primary domain under a first-party, generic URI path (e.g., /assets/app-telemetry.js and /assets/event-sink).

+-----------------------------------------------------------------------------------+
|                        FIRST-PARTY PROXY ARCHITECTURE                             |
+-----------------------------------------------------------------------------------+
                                          |
                      Browser requests: /insights/v-engine.js
                                          |
                        [ Nginx / Caddy Edge Gateway ]
                      (Running on Primary Business Domain)
                                          |
                  Rewrites request internally to Umami VPS:
                    https://analytics-backend.internal/script.js
                                          |
                        Client submits: /insights/t-collector
                                          |
                  Proxied directly to:
                    https://analytics-backend.internal/api/send

Option A: Reverse Proxy via Caddy (Automated TLS)

If you are running Caddy as your primary ingress controller, configure automatic Let’s Encrypt certificates and reverse-proxy paths:

# /etc/caddy/Caddyfile

analytics.yourbrand.pk {
    encode zstd gzip

    # Production Security Headers
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
        Referrer-Policy "strict-origin-when-cross-origin"
    }

    # First-Party Masked Script Endpoint
    handle /lib/telemetry.js {
        rewrite * /script.js
        reverse_proxy 127.0.0.1:3000
    }

    # First-Party Masked Ingestion Endpoint
    handle /api/collect {
        rewrite * /api/send
        reverse_proxy 127.0.0.1:3000 {
            header_up Host {host}
            header_up X-Real-IP {remote_host}
            header_up X-Forwarded-For {remote_host}
            header_up X-Forwarded-Proto {scheme}
        }
    }

    # Default Administration Interface
    handle {
        reverse_proxy 127.0.0.1:3000
    }
}

Reload Caddy:

sudo systemctl reload caddy

Option B: Reverse Proxy via Nginx

For high-concurrency environments running Nginx:

# /etc/nginx/sites-available/analytics.yourbrand.pk

server {
    listen 80;
    server_name analytics.yourbrand.pk;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name analytics.yourbrand.pk;

    ssl_certificate /etc/letsencrypt/live/analytics.yourbrand.pk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/analytics.yourbrand.pk/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # Performance Optimizations
    gzip on;
    gzip_types text/plain application/javascript text/css application/json;
    gzip_min_length 1000;

    # Cloaked Tracking Script
    location = /lib/telemetry.js {
        proxy_pass http://127.0.0.1:3000/script.js;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        expires 1d;
        add_header Cache-Control "public, max-age=86400";
    }

    # Cloaked Ingestion API Endpoint
    location = /api/collect {
        proxy_pass http://127.0.0.1:3000/api/send;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # Buffer tuning for high-frequency writes
        proxy_buffering off;
        proxy_read_timeout 10s;
        proxy_connect_timeout 5s;
    }

    # Administrative Dashboard Access
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Verify and reload Nginx:

sudo nginx -t && sudo systemctl reload nginx

---

5. Client Implementation and Core Web Vitals Optimization

The performance impact of third-party telemetry scripts on Core Web Vitals has become a decisive ranking factor in search engines.

Benchmark Analysis: Umami vs. Legacy Solutions

Performance Attribute	Google Analytics 4 (gtag.js)	Matomo (Self-Hosted)	Umami Analytics (Self-Hosted)
Compressed Payload Size	~45 KB – 95 KB	~22 KB – 40 KB	2.6 KB
Main-Thread CPU Time	80 ms – 220 ms	45 ms – 90 ms	< 6 ms
Cookies Placed	_ga, _gid, _ga_*	_pk_id, _pk_ses	Zero (0)
Consent Banner Required	Mandatory (GDPR/PECR)	Required (if cookies used)	No
Interaction to Next Paint (INP)	High risk of degradation	Moderate risk	Zero impact
Ad-Blocker Sensitivity	Blocked by 30%+ clients	Blocked if unproxied	Fully immune with proxy

Optimized Head Tag Integration

Embed the cloaked tracking script into your website templates (WordPress header.php, Next.js layout.tsx, or static Astro head):

<!-- Production Umami Telemetry Snippet -->
<script
  defer
  src="https://analytics.yourbrand.pk/lib/telemetry.js"
  data-website-id="8f6c3214-9b21-412e-9d24-d576a88e990c"
  data-host-url="https://analytics.yourbrand.pk/api/collect"
  data-auto-track="true">
</script>

The defer attribute guarantees that the script executes strictly after HTML parsing finishes, eliminating render blocking. The data-host-url instructs the script to route metrics to our cloaked ingestion point /api/collect.

---

6. Custom Event Tracking and Conversion Funnels

For Pakistani e-commerce stores operating on WooCommerce or custom headless stacks, tracking macro and micro conversions—specifically Cash on Delivery (COD) submissions, WhatsApp inquiries, and checkout steps—is essential for accurate marketing ROI.

WooCommerce Cash on Delivery (COD) Conversion Tracking

Pakistani online shoppers predominantly utilize Cash on Delivery. To track COD order placements without double-counting reload events, hook directly into WooCommerce’s thank-you lifecycle.

Add this snippet to your active WordPress theme’s functions.php:

/**
 * Fire Umami custom event upon successful WooCommerce order placement
 */
add_action('woocommerce_thankyou', 'nextgen_umami_track_ecommerce_conversion', 20, 1);

function nextgen_umami_track_ecommerce_conversion($order_id) {
    if (!$order_id) return;

    $order = wc_get_order($order_id);
    if (!$order) return;

    // Prevent duplicate firing on page refreshes
    if ($order->get_meta('_umami_conversion_tracked')) {
        return;
    }

    $total_amount   = (float) $order->get_total();
    $payment_method = esc_js($order->get_payment_method());
    $currency       = esc_js($order->get_currency());

    ?>
    <script>
      window.addEventListener('load', function() {
        if (typeof umami !== 'undefined') {
          umami.track('purchase_completed', {
            order_id: '<?php echo esc_js($order_id); ?>',
            revenue: <?php echo $total_amount; ?>,
            currency: '<?php echo $currency; ?>',
            payment_type: '<?php echo $payment_method; ?>'
          });
        }
      });
    </script>
    <?php

    // Mark order as tracked
    $order->update_meta_data('_umami_conversion_tracked', 'yes');
    $order->save();
}

Tracking WhatsApp Direct Inquiries

Direct WhatsApp checkout is ubiquitous among Pakistani retail brands. You can track WhatsApp button clicks declaratively using HTML data attributes or via JavaScript:

<!-- Declarative event tracking -->
<a 
  href="https://wa.me/923001234567?text=Inquiry%20regarding%20product"
  class="whatsapp-order-btn"
  data-umami-event="whatsapp_inquiry_click"
  data-umami-event-product="Cloud-VPS-Tier-2"
  data-umami-event-price="4500">
  Order via WhatsApp
</a>

Alternatively, attach an event listener programmatically:

document.querySelectorAll('.whatsapp-order-btn').forEach(function(button) {
  button.addEventListener('click', function() {
    if (typeof umami !== 'undefined') {
      umami.track('whatsapp_conversion', {
        sku: this.getAttribute('data-product-sku') || 'General',
        page: window.location.pathname
      });
    }
  });
});

---

7. PostgreSQL Performance Tuning and Table Partitioning

When hosting analytics for high-traffic Pakistani news portals or flash-sale marketplaces receiving 5 to 50 million pageviews per month, unpartitioned PostgreSQL tables will inevitably degrade. Sequential queries take seconds, indices exceed physical RAM capacity, and VACUUM operations lock disk I/O.

Tuning postgresql.conf for Write-Heavy Telemetry

Modify PostgreSQL’s memory and disk write buffers inside the container or via an override configuration file:

# /opt/umami/data/postgresql.conf tuning for 8 GB RAM VPS

# Memory Configuration
shared_buffers = 2GB                  # 25% of total server RAM
effective_cache_size = 6GB            # 75% of total server RAM
maintenance_work_mem = 512MB
work_mem = 16MB

# Write-Ahead Log (WAL) Tuning for High Ingestion Rates
wal_buffers = 64MB
checkpoint_completion_target = 0.9
max_wal_size = 4GB
min_wal_size = 512MB
checkpoint_timeout = 15min

# Storage & Optimizer Architecture
random_page_cost = 1.1                # Calibrated for NVMe SSDs
effective_io_concurrency = 200        # Concurrent asynchronous SSD I/O
synchronous_commit = off              # Dramatic write speedup; safe for analytics

Setting synchronous_commit = off provides a major ingestion speedup for write-heavy analytics workloads by flushing transactions in batches while retaining data integrity.

Declarative Range Partitioning on website_event

Umami v2+ records all interactions inside the website_event table. For sites with tens of millions of records, partition this table by the created_at timestamp:

-- Connect to the Umami PostgreSQL database
-- psql -U umami_user -d umami_db

-- Verify current table structures
\d website_event

-- Step 1: Create a monthly partitioned master table
CREATE TABLE website_event_partitioned (
    event_id VARCHAR(36) NOT NULL,
    website_id VARCHAR(36) NOT NULL,
    session_id VARCHAR(36) NOT NULL,
    created_at TIMESTAMP(3) WITH TIME ZONE NOT NULL,
    url_path VARCHAR(500) NOT NULL,
    url_query VARCHAR(500),
    referrer_path VARCHAR(500),
    referrer_query VARCHAR(500),
    referrer_domain VARCHAR(500),
    page_title VARCHAR(500),
    event_type INTEGER DEFAULT 1 NOT NULL,
    event_name VARCHAR(50),
    PRIMARY KEY (event_id, created_at)
) PARTITION BY RANGE (created_at);

-- Step 2: Establish dedicated monthly partitions
CREATE TABLE website_event_y2026m10 PARTITION OF website_event_partitioned
    FOR VALUES FROM ('2026-10-01 00:00:00+00') TO ('2026-11-01 00:00:00+00');

CREATE TABLE website_event_y2026m11 PARTITION OF website_event_partitioned
    FOR VALUES FROM ('2026-11-01 00:00:00+00') TO ('2026-12-01 00:00:00+00');

-- Step 3: Create targeted composite indexes per partition
CREATE INDEX idx_part_2026m10_lookup 
    ON website_event_y2026m10 (website_id, created_at);

CREATE INDEX idx_part_2026m10_session 
    ON website_event_y2026m10 (session_id);

Partitioning ensures that time-windowed dashboard queries (e.g., “Past 24 Hours” or “This Month”) trigger instant index partition pruning, scanning only the current active month and ignoring hundreds of gigabytes of historical records.

Automated Retention and Cleanup Routine

For compliance and storage management, implement a weekly maintenance job via cron:

# Open root crontab
sudo crontab -e

Add an off-peak maintenance script to vacuum and prune raw telemetry older than 18 months:

# Execute every Sunday at 03:00 PKT
0 3 * * 0 docker exec -i umami-db psql -U umami_user -d umami_db -c "VACUUM ANALYZE website_event; VACUUM ANALYZE session;"

---

8. Sizing and Migration: When to Transition from VPS to Dedicated Servers

While a high-performance Linux VPS reliably handles up to 10–15 million pageviews per month, hyper-growth media platforms, ad networks, and multi-tenant agencies monitoring hundreds of client websites eventually face virtualization bottlenecks.

Identifying the Virtualization Bottleneck

• Hypervisor I/O Wait Bottlenecks: When a database executes several thousand writes per second, shared virtualization hypervisors introduce iowait spikes. Even on enterprise clouds, noisy neighbors sharing physical NVMe buses degrade write performance.
• Connection Saturation: Umami running on multiple Next.js worker threads can quickly exhaust database connection pools during viral traffic spikes, requiring massive connection pooling (such as PgBouncer) backed by unconstrained physical CPU cores.
• Aggregated Real-Time Analytics: Agencies running multi-tenant analytics across 500+ domains require sustained high memory to cache active database indices.

When your telemetry platform reaches these thresholds, transitioning to bare-metal infrastructure is the optimal architectural move. Deploying on high-throughput, unthrottled Dedicated Servers provides bare-metal NVMe RAID arrays, dedicated memory bandwidth, and raw CPU cores unencumbered by virtualization overhead.

For organizations demanding ultra-low domestic latency across PTCL, Nayatel, StormFiber, and Transworld networks, utilizing localized Dedicated Servers in Pakistan ensures that incoming tracking telemetry resolves over local fiber routes, keeping analytics ingestion under 15 milliseconds nationwide.

---

9. Comparative Architecture: Umami vs. GA4 vs. Competitors

To justify the engineering investment to stakeholders, evaluate Umami against common alternatives across core technical dimensions:

Architectural Metric	Google Analytics 4	Self-Hosted Umami	Plausible Cloud	Matomo On-Premise
Script Footprint	~50 KB – 100 KB	< 3 KB	~1.5 KB	~25 KB
Data Ownership	Google Infrastructure	100% Private VPS	Vendor Cloud	100% Private VPS
Real-Time Accuracy	24–48h delay	Sub-second Real-Time	Sub-second	Sub-second
Ad-Blocker Immunity	Heavily blocked	Complete (via Proxy)	Partial	Partial
Cost Structure	Free / $50,000+ yr (360)	Flat VPS Hosting	Monthly USD Tiered	Flat VPS Hosting
Database Engine	Proprietary BigQuery	PostgreSQL (Standard)	ClickHouse	MySQL / MariaDB
Cookie Requirement	Mandatory	None (Zero Cookies)	None	Optional
Interface Complexity	High / Steep learning curve	Clean & Intuitive	Clean & Intuitive	Complex / Overwhelming

---

Summary Checklist for Production Deployment

Before redirecting production traffic to your new telemetry cluster, confirm each engineering milestone:

1. Host Hardening: UFW firewall configured, non-root user provisioned, and SSH keys enforced.
2. Container Security: Docker environment isolated via internal bridge network; PostgreSQL ports bound exclusively to internal addresses.
3. Cryptographic Protection: Strong APP_SECRET and distinct database credentials generated via openssl.
4. First-Party Proxy Cloaking: Caddy or Nginx reverse proxy configured to mask /script.js and /api/send under generic paths.
5. Database Tuning: postgresql.conf parameters adjusted for write-heavy performance with synchronous_commit = off.
6. Telemetry Verification: Client-side network tab inspected to confirm zero cookies, 200 OK status on cloaked endpoints, and sub-10ms response times.