A managed database is one whose provisioning, patching, backups, scaling and failover are operated by a cloud vendor. An unmanaged database runs on infrastructure your own team operates. The trade is operational control against operational simplicity, and the same trade applies to every stateful system next to Kafka.
Before the comparison, one belief that shapes how this page reads every row of it. Managed does not mean unmonitored. Providers often do a great job running the infrastructure, and the health of the system stays a shared responsibility, because your topics, your consumers and your data flows are still yours. Teams that treat the managed option as the end of their operational duties meet the same incidents as everyone else, just with less context when they arrive.
At a glance
Managed database and Unmanaged database are scored here on the same four criteria, 40 points in all: Managed database 26 out of 40, Unmanaged database 22 out of 40. Managed database takes its best score on Operational overhead (9 out of 10) and its lowest on Control and security (4 out of 10). Pricing shape: Usage-based: instance hours, storage, transfer. Unmanaged database takes its best score on Control and security (9 out of 10) and its lowest on Operational overhead (3 out of 10). Pricing shape: Infrastructure plus the engineers who run it.
Operational overhead comparison
Self-managing a database means your team owns provisioning, version upgrades, security patching, backup verification, replication topology and the on-call rotation that goes with all of it. For Kafka itself, that operational surface is mapped in the complete Kafka guide. None of that work is a licence line item, which is why it routinely gets left out of cost comparisons and why open source infrastructure is not automatically the cheap option.
Managed services move that work to the vendor. The engineering hours come back, and the control goes with them: the vendor decides upgrade windows, available versions, and which parameters are exposed.
Chad Harris has put a number on this in his writing on Kafka UIs, because “engineering time” stays invisible until you cost it. For something as small as a self-hosted web UI, the deployment and maintenance cost is often half a person, sometimes more. Half a person, for the smallest component in the stack. Scale that honestly across a database, its replicas, its backup verification and its on-call, and the free option has a payroll attached. That is the number to put beside the managed service’s invoice before deciding either way.
Scalability and reliability
Managed services carry published SLAs and handle scaling events without your team in the loop. The same categories exist for Kafka itself, where managed offerings take on cluster provisioning, scaling and operations, and where Kafka-compatible managed engines are their own comparison, covered on cloud brokers. What the SLA does not cover is your own architecture: a managed database still hits its throughput ceiling if a Kafka sink connector writes faster than the storage tier can absorb.
Self-managed reliability is a function of the team that runs it. The realistic question is not whether internal engineering can match a cloud SLA but whether the organisation wants to staff for it, and the answer tends to change as throughput grows, because operational burden compounds with scale.
Reliability numbers deserve a concrete failure to calibrate against. Factor House documented, in the Kafka monitoring guide, a post-incident analysis of a production Kubernetes-hosted Kafka failure that ran to $240,000 in SLA penalties over 62 minutes, a cascading broker crash that pushed consumer lag to 14 hours across 10,000 topics. Managed or self-managed, that is the size of the day you are designing for. And Chad Harris’s standing advice for that day is the same either way: think before acting, and do not reflexively scale. Scaling after you understand the cause is a decision. Scaling instead of understanding it is how one incident becomes two.
Budget pressure is pushing more teams to rethink their Kafka setup; AI spend for some, general cost-cutting for others.
Chad Harris, Solutions Architect at Factor House
Cost architecture
Managed pricing is usage-shaped. Amazon MSK, as one documented example, bills broker instance hours, provisioned storage in GB-months, optional provisioned storage throughput, data transfer, and per-GB rates on its serverless tier (Amazon MSK pricing). The structure is typical of managed data services: cost scales with throughput and retention, and egress between systems is its own line.
An AWS MSK console cluster page, and a redacted bill showing the billing dimensions named here.
Self-managed cost is infrastructure plus people. Compute and storage are usually cheaper per unit, and the engineering payroll that operates them is the balancing item. High-volume event data changes the comparison materially, because retention that is a rounding error at gigabytes is a budget line at terabytes.
Two cost patterns from Factor House’s architecture research are worth carrying into any spreadsheet. On the self-managed side, in the Robinhood architecture writeup, the logging clusters were sized for peak market-hours throughput, which means they sat largely idle on evenings and weekends while still paying inter-AZ transfer on every replicated byte. Fixed capacity priced for your worst hour is the hidden line of self-hosting. On the licensed side, the reference point this page uses is Confluent Platform, where licence pricing typically runs from around $50,000 to $500,000 and up per year. Neither number decides the question for you. Together they bound what “cheaper” actually means at your scale.
Kafka-specific integration
For a database sitting next to Kafka, integration surface matters as much as the engine. Three checks recur:
- Connectors. Whether a maintained Kafka Connect sink and source exists for the engine, and who maintains it. Managed-platform-exclusive connectors are a dependency to price in, because equivalents do not always exist elsewhere.
- Schemas. Compatibility with a schema registry and the serialisation formats in use, Avro or Protobuf being the common cases.
- CDC. Whether change data capture off the database back into Kafka is supported, Debezium being the standard open source route, which traditionally requires a Kafka Connect cluster between the database and the consumers (Debezium vs Kafka Connect covers when each applies).
The integration check this page weights highest is CDC, because it couples the database to every downstream consumer. In the Shopify architecture writeup, the team identified breaking changes to internal database schemas propagating to CDC consumers as an active risk they had to engineer around. The lesson carries directly to this decision: whichever database you choose, managed or not, the schema contract between it and your Kafka consumers is a production interface, and it deserves the same review discipline as a public API.
Control and security
Self-managed wins where the requirement is control itself: a pinned engine version, hardware choices, deep parameter tuning, or a compliance regime that dictates where data physically lives. Managed services narrow the exposed configuration surface by design.
The security boundary also moves. A managed database means data and credentials inside a vendor’s control plane, so data sovereignty and network isolation requirements, private VPC deployment alongside the Kafka cluster included, need checking against what the vendor offers rather than assuming parity with self-hosting. Governance does not disappear with the broker maintenance: schemas, topic growth and access control remain internal work whichever side of the trade is chosen. The broker-side version of this whole decision sits on Kafka vs other brokers.
Control cuts both ways, and self-hosting hands you the failure modes along with the keys. A common one documented in Factor House’s Kafka security work: teams secure the brokers carefully and leave ZooKeeper reachable on a trusted internal network, which hands a compromised host a path to the cluster’s control plane. The lesson: if you take the self-managed side of this trade for control or compliance reasons, the security perimeter you now own includes every coordination and metadata service, not just the engine your auditors asked about.
The two options are marked out of 10 on four criteria, 40 points in all, with no criterion weighted above another, each one a section of this page. Operational overhead is the work your own team carries. Scaling and SLAs is who absorbs a scaling event and what reliability is contracted. Cost architecture is how the bill is shaped, and control and security is how much of the configuration, version and security boundary stays yours. They are scored level on cost because neither shape is cheaper at every scale.
Managed database
Operated by a cloud vendor
26 out of 40 Total
- Who operates it
- The cloud vendor
- Pricing shape
- Usage-based: instance hours, storage, transfer
- Operational overhead
- 9 out of 10
- Scaling and SLAs
- 8 out of 10
- Cost architecture
- 5 out of 10
- Control and security
- 4 out of 10
Why these scores for Managed database
- Operational overhead 9 out of 10
- Provisioning, patching, backups, scaling and failover move to the vendor and the engineering hours come back, though health stays a shared responsibility.
- Scaling and SLAs 8 out of 10
- Published SLAs and scaling handled without your team in the loop, but the SLA does not cover your own architecture, such as a sink connector writing faster than the storage tier absorbs.
- Cost architecture 5 out of 10
- The bill scales with throughput and retention, and egress between systems is its own line.
- Control and security 4 out of 10
- The vendor decides upgrade windows, available versions and exposed parameters, and data and credentials sit inside the vendor’s control plane.
What you give up. Control of upgrade windows, engine versions and exposed parameters, in exchange for the provisioning, patching, backup and failover work the vendor now carries.
Unmanaged database
Operated by your own team
22 out of 40 Total
- Who operates it
- Your own team, including on-call
- Pricing shape
- Infrastructure plus the engineers who run it
- Operational overhead
- 3 out of 10
- Scaling and SLAs
- 5 out of 10
- Cost architecture
- 5 out of 10
- Control and security
- 9 out of 10
Why these scores for Unmanaged database
- Operational overhead 3 out of 10
- Your team owns provisioning, upgrades, patching, backup verification, replication topology and the on-call rotation, and none of it is a licence line item.
- Scaling and SLAs 5 out of 10
- Reliability is a function of the team that runs it, and the operational burden compounds as throughput grows.
- Cost architecture 5 out of 10
- Compute and storage are usually cheaper per unit, with the engineering payroll as the balancing item and fixed capacity sized for the worst hour.
- Control and security 9 out of 10
- It wins where control itself is the requirement, a pinned version, hardware choice or where data physically lives, but the security perimeter you own includes every coordination and metadata service.
What you take on. Every version upgrade, security patch, backup check and failover, plus the on-call rotation behind them, in exchange for a pinned engine version, your own hardware choices and full control of where the data lives.
FAQ
Can Kafka be used as a database?
Kafka is a durable, replayable log, not a database: it retains records and lets consumers re-read them, but the databases in your architecture sit beside it, connected through Kafka Connect sinks and sources or change data capture. The managed-versus-self-managed trade on this page applies to those databases the same way it applies to the cluster.
What is Apache Kafka and how is it used?
Kafka is a distributed event-streaming platform built on a partitioned, append-only log, used as the backbone for event streaming, log aggregation and change data capture. What is Apache Kafka? covers it in full.
How these options were scored
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. Each criterion counts once, for a total out of 40. The options are listed by total.