PostHog Rewrites Feature Flag Service in Rust, Cuts Resource Use by 95%.

PostHog has rewritten its local feature flag evaluation service in Rust, reducing resource consumption from 30 Django pods running on 60 cores and 270GB of RAM to just 5 pods on 2.5 cores and 5GB of RAM while handling the same traffic load. The company shared the engineering details in a post by engineer Patricio Tarantino, revealing that the headline numbers mask a more complex migration that required reimplementing undocumented behavior across every API endpoint.

The service handles feature flag polling from PostHog's SDKs, which check for flag updates across thousands of customer deployments. The Django version had become a bottleneck, consuming significant infrastructure resources as PostHog scaled.

The Rust implementation achieves a 99.98% cache hit rate by serving nearly all requests directly from Redis, keeping Postgres entirely off the hot path. The architecture prioritizes cache lookups, falling back to the database only when a flag definition is missing or stale.

ETags handle a second layer of optimization. The Rust service reads ETags from Redis and returns 304 Not Modified responses when SDK polls haven't changed, eliminating the need to serialize and transfer flag data. This approach now accounts for 54% of all requests, cutting bandwidth usage in half.

The team split the service into two workloads using a SERVICE_MODE environment variable. One set of pods handles /flags and /decide endpoints, which serve real-time evaluation requests, while another handles /flags/definitions for bursty polling traffic. Separating these workloads prevented resource contention between spiky evaluation and steady polling patterns.

Matching Django's behavior request-for-request consumed most of the engineering effort. Authentication proved particularly difficult: a shared Django mixin had quietly added multiple authentication methods over time, and subtle differences in error codes (403 in Django, 401 in Rust) caused dashboard metrics to disagree during parallel testing.

The team had to reimplement Redis counters, allowlists, and quota response codes on the Rust side to maintain identical behavior. Every edge case the old service handled, documented or not, needed to be reproduced. "A rewrite that looks like a 'just port it' job is often an exercise in reproducing every undocumented edge the old service had," PostHog noted in their LinkedIn post.

PostHog has been investing heavily in infrastructure efficiency across its platform. The company previously launched a managed warehouse built on DuckDB and introduced an AI-powered setup wizard to streamline developer onboarding.

The Rust migration follows a pattern seen across the analytics and infrastructure space, where high-throughput services are moving from Python-based stacks to compiled languages. Similar rewrites at Vercel and Supabase have delivered comparable resource reductions, though few have documented the engineering complexity as thoroughly as PostHog's team.

The full technical breakdown, including cache strategy details and authentication fixes, is available in Tarantino's blog post. PostHog's feature flag service is part of its open-source product analytics platform, which competes with proprietary tools by offering self-hosted deployment and full data control.