How We Keep Mobile Session Replay 17× Cheaper Than PostHog

PostHog bills around $85/month for 25,000 sessions.

Rejourney bills $5/month.

At higher volumes, the gap gets even wider. At 350,000 sessions/month, Rejourney is roughly 20× cheaper.

This post is not about pricing strategy but why those numbers are technically sustainable.

The answer is not one trick. It is a stack of engineering decisions that each remove a unit of cost that would otherwise compound with volume.

Price Comparison

1. SDK Bandwidth: Every Byte Has to Be Stored and Served

Most session replay tools capture at the device’s native resolution because it is the simplest implementation.

We do not.

The Rejourney SDK captures at 1.25× scale, meaning we read the framebuffer at roughly 80% of its linear dimension before compression.

Compared with 3× Retina, that reduces raw pixel count by about 5.8× before JPEG compression even begins.

That matters because every pixel captured by the SDK eventually becomes:

• CPU work
• memory pressure
• upload bandwidth
• object storage
• replay egress

The frame rate is also intentionally conservative.

Our default is 1 frame per second. The capture timer runs in UIKit’s default run loop mode instead of .common, which means the timer naturally pauses while UIKit handles active scroll events.

We are not manually slowing down during scrolls. The run loop simply does not fire the timer.

A tool capturing at 10 FPS can easily generate around 10× more screenshot data per session before any other cost factor is considered.

Background Encoding and Backpressure

The main thread is only involved for the pixel read.

Everything else runs on a serial background OperationQueue at .utility QoS:

• JPEG encoding
• frame batching
• gzip compression
• HTTP upload

The encode queue also has hard backpressure limits:

• 50 pending batches
• 500 buffered frames

When either limit is reached, new frames are dropped instead of queued indefinitely.

That prevents a network outage from becoming unbounded memory growth.

On-Device Redaction

Redaction happens before encoding.

Text inputs, password fields, and camera previews are blacked out directly in the pixel buffer before the JPEG encoder runs.

That means sensitive pixels never leave the device and never enter the artifact.

It also removes the need for a server-side blurring pipeline, which means one less compute stage and one less storage operation per session.

2. Compression: Binary Frame Bundles + Gzip

Frames are not uploaded individually.

After JPEG encoding, frames are packed into a binary archive and gzip-compressed as a single unit.

The binary format is deliberately simple.

[ 8 bytes — uint64 BE ] timestamp offset from session epoch, in ms
[ 4 bytes — uint32 BE ] JPEG byte length
[ N bytes            ] raw JPEG data

...repeated for each frame in the batch...

→ entire archive passed to gzipCompress()

There is no alignment padding and no unnecessary per-frame metadata.

The gzip pass uses zlib’s deflateInit2_ with compression level 9.

deflateInit2_(
    &stream,
    9,               // Z_BEST_COMPRESSION
    Z_DEFLATED,
    MAX_WBITS + 16,  // gzip container
    8,               // memLevel
    Z_DEFAULT_STRATEGY,
    ZLIB_VERSION,
    MemoryLayout<z_stream>.size
)

Level 9 costs more CPU than level 6, but for our workload, the tradeoff is worth it.

The compression work runs at .utility QoS, so it happens on background CPU. The smaller payload wins later at the storage and egress layer every time the artifact is read back.

Flush Behavior

Batches flush when either condition is met:

• The buffer reaches the upload batch size, defaulting to 3 frames.
• The oldest buffered frame has waited longer than batchSize × snapshotInterval.

The time-based flush is specifically for short sessions.

Without it, a 2-second session could end before ever accumulating a full batch.

Hierarchy snapshots go through the same gzip compression path independently, so every artifact type leaving the device is compressed.

3. Ingest Pipeline: Object Storage Is Not in the SDK Request Path

A common session replay ingest pattern looks like this:

SDK upload
→ server presigns PUT URL
→ SDK uploads to object storage
→ server records artifact metadata

That makes object storage latency part of the SDK upload path.

If S3 is slow, the ingest service is slow.

We separate those concerns.

When the SDK uploads an artifact body, the ingest relay writes it into Redis under:

artifact:buf:{artifactId}

with a 30-minute TTL, then immediately returns 204.

The SDK is done in under 50ms regardless of what object storage is doing.

Actual object storage writes happen asynchronously through a BullMQ worker on the rj-artifact-flush queue.

Why This Works

BullMQ deduplicates flush jobs by artifactId.

If a worker crashes mid-flush, the job becomes stalled and is automatically requeued after 30 seconds for up to three attempts.

The flush operation is idempotent. Writing the same artifact to object storage twice is safe.

Redis TTL acts as a circuit breaker. If the artifact is not flushed within 30 minutes, it is dropped rather than left orphaned.

In practice, flush jobs complete in seconds. The TTL exists for pathological failure, not normal operation.

The result is that the ingest relay pod stays stateless and cheap.

It never waits on object storage latency and scales horizontally with upload volume.

4. Storage Routing: No Hard-Coded Buckets

Every artifact is pinned to the endpoint that received it through a storage_endpoints table in Postgres.

At write time, the flush worker resolves an endpoint:

• project-specific override, or
• global default selected by weight

It writes the artifact, then stores the endpoint ID with the artifact metadata.

Reads always look up the endpoint from the artifact record instead of assuming one global bucket.

That makes bucket migration operational instead of architectural.

We can add a new endpoint, shift its weight to 100%, and drain the old bucket without changing application code or breaking old artifacts.

Every artifact knows where it lives.

Current Storage Strategy

Our current provider is OVH.

The main reasons are:

• cheap storage
• free egress
• free ingress
• no API operation costs
• mature object storage platform
• high object-count tolerance

After the primary write, shadow endpoints receive async copies for durability without slowing down the hot path.

Postgres WAL archiving and compressed database backups go to Cloudflare R2, where zero-egress reads are useful for rare backup and archival access.

5. Database: CloudNativePG Instead of Managed Databases

Managed database services like RDS, Cloud SQL, and Supabase charge a premium for operations.

We run Postgres using CloudNativePG, the CNCF-graduated Kubernetes operator for Postgres.

Our setup:

• primary Postgres instance in one datacenter
• synchronous standby in a second datacenter
• synchronous_commit = remote_write
• pgbouncer in front of Postgres

With remote_write, the standby has the write before the primary acknowledges it. If the primary fails, auto-promotion takes roughly 30 seconds, and pgbouncer follows the new primary.

Why pgbouncer Matters

Session replay ingest creates many short-lived database interactions.

Each worker job may open and release a database connection.

Without pooling, Postgres would waste CPU on connection setup and teardown.

pgbouncer keeps around 180 connections to Postgres while exposing a higher connection limit to the application layer.

That keeps Postgres focused on query work instead of connection churn.

Redis HA

Redis runs as a three-node Sentinel cluster.

Sentinel requires a quorum of 2 out of 3 nodes to elect a new master.

One important configuration choice:

maxmemory-policy = noeviction

For BullMQ job state, silent eviction would be dangerous. It could make jobs disappear without processing.

Instead, Redis returns an error when memory is full, and we treat that as a backpressure signal.

6. Compute: k3s on European VPS Instead of Managed Kubernetes

Managed Kubernetes on AWS, GCP, or Azure has two major costs:

• the worker nodes
• the managed control plane

The control plane fee is fixed regardless of load, and full Kubernetes distributions can consume several gigabytes of RAM per node before application pods even run.

We use k3s.

k3s ships as a single binary, embeds etcd, and has a much smaller memory footprint.

That means more of the machine’s RAM goes to actual workloads.

We run the cluster on Hetzner across two EU datacenters.

Worker workloads that process bulk session artifacts run in the second datacenter, keeping the primary node’s CPU available for lower-latency API traffic.

These workers are mostly I/O-bound, so they autoscale on BullMQ queue depth instead of CPU utilization.

7. GDPR Data Residency

The infrastructure is designed around EU data residency.

The ingest path is:

SDK
→ Cloudflare WAF
→ load balancer
→ Rejourney API
→ Redis / Postgres / object storage

All compute runs in the EU, primarily Germany and Finland.

Cloudflare is used for TLS termination and WAF behavior, not persistent session replay storage.

The iOS SDK also ships with PrivacyInfo.xcprivacy, so App Store privacy API usage declarations are handled automatically.

Conclusion

The cost difference comes from reducing cost at every layer:

• fewer pixels captured
• lower frame rate
• background compression
• strict SDK backpressure
• on-device redaction
• binary frame bundles
• Redis-buffered ingest
• async object storage flushing
• endpoint-aware storage routing
• self-operated Postgres with CloudNativePG
• k3s instead of managed Kubernetes
• EU VPS infrastructure
• storage providers selected for low egress and operational flexibility

Session replay is expensive when every session creates too much data and every request touches too many expensive systems.

Rejourney stays cheap because the expensive parts are avoided, compressed, delayed, or moved out of the hot path.