Minimal Dependencies, Minimal Cost: Choosing a Low-Maintenance Self-hosted Stack
The number of infrastructure components in your feature flag stack has a direct, compounding effect on long-term operations cost. This page explains the dependency-cost chain, compares common stack architectures by ops burden, and shows how to design a deployment that stays cheap to maintain.
TL;DR
- ▸Standalone uses only PostgreSQL — as both the primary database and the message queue (via LISTEN/NOTIFY) — with no Redis or Kafka required. It is the lowest-ops starting point.
- ▸Standard adds Redis for both pub/sub messaging and caching, and supports Postgres or MongoDB as the primary database. It suits larger teams and higher-volume deployments.
- ▸Professional adds Kafka (for high-throughput messaging) and ClickHouse (for large-scale analytics). It is designed for high-traffic apps with advanced experimentation needs.
- ▸Each additional infrastructure component compounds ops burden. Start from Standalone and upgrade tiers only when benchmarks indicate a specific need, not by default.
- ▸Most teams already run Postgres — and Redis for teams moving to Standard. FeatBit reuses your existing data services and only requires a one-time DB schema initialization. Incremental infrastructure cost for Standalone is near-zero for teams already on Postgres.
- ▸A mid-size org (50 engineers) self-hosting FeatBit spends ~$953/mo total (infra + ops labor + license) vs ~$3,830/mo on SaaS — roughly $34,500/year in savings with a ~4-month payback.
The Dependency Cost Chain
Every component new to your stack has a recurring ops cost. The key word is new — if your team already operates Postgres and Redis, those costs are already on your team's books long before FeatBit enters the picture. Adding FeatBit Standalone does not add a new database to maintain; it adds a DB schema initialization on top of infrastructure you already run.
For FeatBit Standalone, the only genuinely new components are the three FeatBit application containers (UI, API, ELS). Postgres is reused from your existing stack. There is no broker and no cache to manage on top of what you already operate. Standard adds Redis only as a new component if you do not currently run it. The Professional tier adds Kafka and ClickHouse — those are real additions that warrant this analysis. Starting from Standalone means your incremental ops exposure is minimal by design.
Self-host vs SaaS: What You Actually Pay
SaaS feature flag billing compounds across six independent meters — seats, request/CDN traffic, MAU, service connections, logs/eval metrics, and governance tier. A successful product launch grows MAU (③), more K8s pods mean more service connections (④), and growth requires stricter governance (⑥). All six meters can move simultaneously. Self-hosting replaces all six with a flat, predictable cost profile.
| Cost item | Small (15 eng) | Mid (50 eng) | Enterprise (150 eng) |
|---|---|---|---|
| SaaS all-in /year | $8,400 | $45,960 | $148,560 |
| FeatBit self-host /year (incl. license) | $8,676 | $11,436 | $18,760 |
| Annual gross savings | −$276 | $34,524 | $129,800 |
| Simple payback period | — | ~4 months | ~2 months |
Self-host cost = infra + ops labor (3–5h/mo @ $150) + monitoring + FeatBit Enterprise license (~$333/mo). Small teams are cost-neutral; the financial case at small scale is data sovereignty, not savings. See the full ROI calculator for detailed inputs and line-item breakdowns.
Why Self-host Cost Stays Low: Infrastructure You Already Operate
Most teams already run Postgres in production — and increasingly Redis as well. FeatBit Standalone requires only that you point it at an existing Postgres instance and run a DB init script. The ops cost for that Postgres instance was already on your team's books before FeatBit. Only what is new to your stack adds to your ops burden.
| FeatBit tier | Infra needed | If already in your stack | Ops h/mo (automated) |
|---|---|---|---|
| Standalone | Postgres (DB + MQ via LISTEN/NOTIFY, no cache) | Postgres → incremental infra cost = $0 | 1–2h |
| Standard | Postgres/MongoDB + Redis (MQ + Cache) | Postgres + Redis → incremental infra cost = $0 | 2–4h |
| Professional | Postgres/MongoDB + Redis + Kafka + ClickHouse | Adds Kafka + ClickHouse (new ops surface) | 5–8h |
Automated hours assume CI/CD upgrade pipeline, automated backup restore tests, and cloud secrets rotation. Manual ops baseline: Standalone 3–5h/mo, Standard 6–10h/mo, Professional 14–22h/mo.
Designing a Minimal Stack
Start with Standalone: Postgres does double duty
In Standalone mode, FeatBit uses Postgres as both the primary database and the message queue — via LISTEN/NOTIFY for real-time flag-change delivery and batch polling with timestamp ordering for background jobs. No separate broker or cache is required. This is the lowest-ops starting point for most teams.
Upgrade to Standard only when Redis is warranted
Standard mode adds Redis for PUB/SUB messaging and caching. The ELS reads flag data from Redis while the API keeps it up to date. This improves throughput when horizontal SDK connections increase. Add Redis when benchmarks show the need or when your org already operates Redis — not preemptively.
Avoid per-environment database sharding
Some platforms shard environments into separate database schemas or separate DB clusters for isolation. This multiplies DBA tasks linearly with environment count. Prefer logical isolation within a single Postgres or MongoDB database. FeatBit supports both.
Reserve Kafka and ClickHouse for Pro-scale workloads
Professional mode adds Kafka for high-throughput, durable message streaming across services, and ClickHouse for large-scale analytics on flag evaluations and experiment data. Both add significant ops overhead — broker replication, consumer group lag monitoring, ClickHouse shard management. Add them only for concrete high-traffic or analytics requirements.
FeatBit's Deployment Tiers
FeatBit offers three deployment modes with the same application services but different infrastructure beneath them. Each tier provides identical core feature flag functionality while differing in performance ceiling and ops complexity.
For high-availability Standalone or Standard deployments, Postgres and Redis can be run as managed services (RDS, Cloud SQL, Azure Database for PostgreSQL, ElastiCache), reducing database ops burden significantly without changing the application layer.
FAQ
When should I upgrade from Standalone to Standard?
The main trigger is MAU growth. As MAU increases, the Evaluation Server (ELS) handles more concurrent SDK connections — each requiring flag rules and targeting data from Postgres. Standard mode moves that hot data into Redis, so the ELS reads from Redis instead of the database under high concurrency. Upgrade when Postgres read latency climbs under evaluation load, or proactively if your org already runs Redis.
Does Standalone mode mean lower performance?
Not for typical feature-flag workloads. Standalone runs comfortably on 2 vCPU and 4 GB RAM for normal usage. Postgres LISTEN/NOTIFY delivers flag changes to SDKs in real time without a separate broker. Run the published FeatBit benchmark against your expected load before concluding that Redis or Kafka is required.
Is a minimal stack less secure than a multi-tier architecture?
Security is determined by network policy, authentication, and access controls — not by the number of components. A well-hardened Standalone deployment is more secure than a poorly configured five-component one. Fewer network interfaces means a smaller attack surface.