DEV Community: Mohammad R. Rashid

How We Keep Mobile Session Replay 17x Cheaper Than PostHog

Mohammad R. Rashid — Mon, 18 May 2026 03:25:40 +0000

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

Sessions / Month	Rejourney	PostHog	Cheaper By
25,000	$5/mo	$85/mo	17×
100,000	$15/mo	$272.50/mo	18×
350,000	$35/mo	$712.50/mo	20×

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.

Rejourney Session Replay Now Open Beta for Swift

Mohammad R. Rashid — Tue, 05 May 2026 19:20:45 +0000

After nearly 3 months of battle testing our React Native package, and recording over 1.5 million session replays from users all over the world, we now have public open beta for our Swift Package.

The Swift package follows a lot of the design decisions for React Native iOS as that was also built in Native Swift for performance.

What We Reused From React Native

Our React Native package is where the recorder became boring in the best sense. It forced the native iOS and Android engines to survive real app startup races, navigation churn, background/foreground rollover, custom URLSession stacks, offline uploads, and aggressively animated screens. The Swift Package keeps that native core model.

The reusable unit was never the JavaScript API. The reusable unit was the native capture pipeline: DeviceRegistrar establishes identity and upload credentials,ReplayOrchestrator owns the session state machine, VisualCaptureand ViewHierarchyScanner produce time-aligned artifacts, andSegmentDispatcher ships compressed payloads into the same production ingest routes used by React Native.

The Direction From Here

The Swift Package lets us treat native iOS as a first-class integration target instead of a platform implementation detail behind React Native. The important part is that we got there without forking the product model: sessions, artifacts, replay timelines, upload credentials, sampling, observe-only mode, and backend finalization still speak the same protocol.

That is the architectural line we want to keep: different host runtimes, shared replay semantics. React Native will continue to drive cross-platform ergonomics. SwiftPM will let us go deeper on iOS-specific correctness, performance, and privacy. The beta is the point where those two tracks stop blocking each other.

How we scaled to 1.3 MILLION Session Replays

Mohammad R. Rashid — Fri, 24 Apr 2026 02:23:41 +0000

Rejourney.co has scaled to over 1.3 MILLION session replays from app developers over the world.

Rejourney is an alternative to sentry.io and posthog.com for indie React Native developers.

Quick growth for any startup is hard. However, the difficulty is far greater when your startup handles hundreds to thousands of small files ingested every minute. Every startup dreams of that "hockey stick" moment, but as we recently learned at Rejourney, the infrastructure that supports 10,000 sessions a day doesn't always handle 100,000 with the same grace.

Last month, we officially onboarded new customers with expansive user bases across several high-traffic mobile apps. It was a milestone for our team, but it also quickly became an "all-hands-on-deck" engineering challenge.

The "Accidental" DDoS

The trouble started almost immediately after they loaded Rejourney live on their apps. Within minutes, our ingestion metrics spiked by an order of magnitude.

At the edge, Cloudflare’s automated security systems saw this sudden, massive influx of traffic to our API and did exactly what they were programmed to do: they flagged it as a Distributed Denial of Service (DDoS) attack. Legitimate session data from thousands of users was being dropped before it even reached our infrastructure.

Our immediate fix was to implement a bypass filter for our specific API endpoint. We wanted to ensure no data was lost and that the onboarding experience was seamless. We flipped the switch, the "Attack Mode" subsided, and the floodgates opened.

Thundering Herd

Opening the floodgates is only a good idea if your reservoir can handle the volume. By bypassing the edge protection, we redirected the full, unthrottled weight of the traffic directly to our origin server.

At the time, our backend was running on a single-node K3s cluster. While we’ve optimized our ingestion pipeline to be lean, no single node is immune to a "thundering herd." As thousands of concurrent connections hit our API, our Ingest Pods were pinned at Max CPU, and the server eventually became unresponsive.

We realized that scaling "up" (getting a bigger VPS) was no longer enough. We needed to scale "out."

Decomposing the Ingestion Pipeline

Session lifecycle architecture from SDK start through upload lanes, workers, and reconciliation

Session lifecycle overview: upload lanes, durable queue boundary, workers, and reconciliation.

The biggest bottleneck in our old setup was the "monolithic" nature of ingestion. If a pod restarted, in-memory tasks were lost. We’ve now decomposed the pipeline into five specialized, durable stages:

The Control Plane (API): Our API pods now focus exclusively on the "handshake." When the SDK calls our endpoints, we immediately create durable rows in Postgres (via PgBouncer) to track the session and ingest jobs.

The Upload Relay: We isolated heavy client upload traffic into its own ingest-upload layer. These pods act as a relay to Hetzner S3, ensuring that a flood of incoming bytes doesn't starve our core API of resources.

The Durable Queue Boundary: We moved away from in-memory task management. Work is now represented as durable rows in Postgres. If a worker pod crashes or restarts, the job still exists in the database, waiting to be claimed.

Specialized Worker Deployments: We split our processing power. ingest-workers handle lightweight metadata like events and crashes, while replay-workers tackle the heavy lifting of screenshots and hierarchies.

Self-Healing Reconciliation: A dedicated session-lifecycle-worker performs periodic sweeps to recover stuck states or abandon expired artifacts.

By using Postgres as the source of truth for state and S3 for storage, our system is now remarkably resilient. Even if Redis or individual pods face transient issues, the state survives and processing resumes exactly where it left off.

High-Availability Postgres and Redis

We’ve moved away from the single-node bottleneck to a High Availability configuration. We now run HA Postgres and Redis with automated failover. If a VPS goes down, the databases automatically fall back to a replica. The platform keeps moving, and the data stays safe.

K3s cloud setup showing ingress, API, workers, and data services

K3s cloud setup: ingress, app services, workers, and HA data plane.

Before

Single-node Postgres and Redis tied to one VPS.

Infrastructure maintenance had direct outage risk.

No automated failover path during node loss.

After

HA Postgres and Redis replicated across nodes.

Automated failover promotes healthy replicas quickly.

Platform continuity during host-level interruptions.

Navigating the 50 Million Object Limit

As we scaled, we hit a literal physical limit: providers like Hetzner often impose a 50-million-object limit per bucket. To bypass this, we implemented a dynamic multi-bucket topology.

Instead of hard-coding storage locations in environment variables, we moved the source of truth to a storage_endpoints table in Postgres. This allows us to manage storage with extreme granularity:

Multi-bucket topology with endpoint resolution, artifact pinning, and shadow replication

Multi-bucket topology: endpoint routing, artifact pinning, and shadow durability.

Weighted Traffic Splitting: We can resolve active buckets and perform weighted random selection to balance load across providers.

Artifact Pinning: To avoid "File Not Found" errors during migrations, we store the specific endpoint_id on every artifact. This "pins" future reads to the correct bucket, even as global defaults change.

Shadow Copies for Durability: We implemented a "Shadow" role. Once a primary write succeeds, we fan out asynchronous writes to shadow targets for extra redundancy.

Efficiency at Scale

Despite the intensity of the traffic spike, we managed to implement these changes with less than five minutes of total downtime.

This incident reinforced why we focus so much on performance. Our lightweight SDK ensures we aren't taxing the user’s device, while our new HA infrastructure ensures we can handle whatever volume the next "hockey stick" growth moment throws at us.

We’re now back to 100% stability, with a much larger "reservoir" ready for the next wave of growth. If you’ve been looking for a session replay tool that respects your app’s performance as much as you do, we’re more ready for you than ever.

Rollout Timeline

Detected false-positive edge protection and restored trusted API traffic.

Isolated upload traffic and shifted orchestration state to durable Postgres rows.

Split workers by workload, then added reconciliation for crash-safe recovery.

Enabled HA Postgres + Redis and finalized multi-bucket endpoint routing.