containerd vs. Docker: What’s the Difference?

If you’re working with containers in the modern day, chances are you’ve heard of both Docker and containerd (official brand name is written in lowercase). You might even be using them without realizing how they differ—or that they’re related in the first place. As container adoption continues to climb (Gartner projects that over 90% of global organizations will be running containerized applications in production by 2026), understanding the nuances between these tools isn’t just a technical curiosity—it’s critical to making smart architecture decisions.

Docker revolutionized the developer experience in the early 2010s, making it easier than ever to build and ship software. But behind the scenes, containerd quietly became the runtime of choice for Kubernetes and other major platforms. In fact, containerd now powers container execution in everything from AWS Fargate to Google Kubernetes Engine. So what exactly is containerd? Is Docker still relevant? And when should you use one over the other?

Let’s break it down.

What Is Docker?

Although it’s become synonymous with the word “container,” Docker itself isn’t a container but rather a very popular developer tool for creating, working with, and managing containers. In other words, it’s a container engine, a system that allows code developed in one computing environment to work in another computing environment. In this way, Docker is really a facilitator and enabler of application development. It’s a software platform that simplifies the process of building, running, managing, and distributing applications, and it achieves this by virtualizing the operating system of the computer on which it’s installed and running. 

Containers are the portable, self-contained environments that Docker and other container engines, such as CRI-O, RKT, and LXD, use to package, ship, and run applications. A container runtime such as containerd, the container runtime developed by Docker, is a component of a container engine that mounts the container and works with the operating system kernel to start and support the containerization process. 

What Is containerd?

containerd is a Docker-developed container runtime that manages the life cycle of a container on a physical or virtual machine (i.e., a host). It creates, starts, stops, and destroys containers. It can also pull container images from container registries, mount storage, and enable networking for a container.

Since its graduation from the Cloud Native Computing Foundation (CNCF) in 2019, containerd has emerged as a core building block of modern containerized infrastructure. 

Recent versions (1.7 and above) have introduced:

• Improved image management with native support for lazy image pulling and remote snapshots
  
• Enhanced security features, such as seccomp filters, AppArmor, and rootless container support
  
• Better extensibility via runtime plugins and gRPC APIs
  
• Support for OCI v1.1 image and runtime specs

Meanwhile, Docker, though now leveraging containerd under the hood, continues to innovate at the developer-experience level. It integrates containerd with additional developer-friendly tooling like BuildKit and Docker Desktop, maintaining its popularity for local development workflows.

Open Container Initiative (OCI) and Why It Matters

The Open Container Initiative (OCI), a Linux Foundation project started in 2015, established open, vendor-neutral standards for container image formats and runtime behavior. These specifications help ensure interoperability, portability, and security across the container ecosystem.

Key OCI specs:

• OCI Runtime Specification: Defines how containers should be launched and managed.
  
• OCI Image Specification: Standardizes the format for container images.
  
• OCI Distribution Specification: Describes the protocol for image registries.

containerd is a reference implementation of these specifications, offering a compliant and modular runtime that can run any OCI-compliant image. It also integrates with projects like runc for low-level container execution, maintaining strict adherence to runtime standards.

Standardization through OCI allows organizations to avoid vendor lock-in, simplifies container lifecycle management, and promotes broader community innovation.

Comparing containerd and CRI-O: Kubernetes Container Runtime Interfaces

Both containerd and CRI-O are popular choices for Kubernetes environments that use the Container Runtime Interface (CRI)—an abstraction layer that allows Kubernetes to communicate with underlying container runtimes.

While both runtimes are mature and production-ready, the choice between them often depends on ecosystem alignment:

• Choose containerd for broader integration and flexibility (e.g., Docker compatibility, multi-use cases).
  
• Choose CRI-O for minimalism and tighter Kubernetes conformance (especially in Red Hat-based stacks).

How containerd Works

containerd is a daemon, meaning it’s a computer program that runs as a background process rather than being under the direct control of an interactive user. It’s available for both Linux and Windows. 

Figure 1: How containerd works. Source: Docker 

containerd manages the complete container life cycle of its host system—from image transfer and storage to container execution and supervision to low-level storage to network attachments and more.

The Modern Container Ecosystem

Docker Desktop Alternatives

Since Docker’s licensing changes, a number of alternative container management tools have emerged, offering flexible, often open-source options for developers and enterprises. Some of the most popular Docker Desktop alternatives include:

• Rancher Desktop: A Kubernetes-focused GUI tool that includes containerd and nerdctl under the hood, making it a strong open-source option.
  
• Podman: A daemonless container engine that offers Docker CLI compatibility and supports rootless containers, enhancing security.
  
• Minikube: Though primarily a lightweight Kubernetes distribution, Minikube also allows users to run containers locally, making it a solid replacement in development environments.
  
• Lima + nerdctl: On macOS, Lima allows users to run Linux virtual machines with containerd and nerdctl, mimicking Docker CLI behavior.

These alternatives offer developers more control over licensing, architecture, and integration with Kubernetes-native tooling—making them increasingly popular for enterprise development teams focused on cloud-native workflows.

Kubernetes Integration

As Kubernetes has become the de facto orchestration platform, container runtimes like containerd have taken center stage. Containerd is now the default runtime for most Kubernetes distributions, replacing Docker in newer Kubernetes versions (v1.20+).

For database workloads in Kubernetes, some best practices include:

• Persistent storage: Use Container Storage Interface (CSI) drivers (e.g., Pure Storage’s CSI driver) to ensure reliable, scalable persistent volumes.
  
• StatefulSets and PVCs: Deploy databases via StatefulSets to maintain stable network identities and persistent storage across pod restarts.
  
• Tolerations and affinity rules: Use node affinity and anti-affinity rules to ensure high availability and resource isolation.
  
• Backup and DR: Leverage tools like Velero or Portworx for automated backups, volume snapshots, and disaster recovery within Kubernetes clusters.

Modern Kubernetes setups often rely on containerd because of its lighter footprint, improved security posture, and native Kubernetes support, particularly for high-performance, stateful applications like databases.

Database-Specific Considerations in Containerized Environments

Containerized Databases: Benefits and Challenges

Running databases in containers offers agility, portability, and consistency—especially for development, CI/CD pipelines, and microservices architectures. Benefits include:

• Rapid provisioning and teardown for testing and staging
  
• Environment consistency across dev, test, and prod
  
• Improved scalability through orchestrators like Kubernetes or Swarm

However, containerizing databases also introduces challenges:

• Data persistence must be carefully managed across container restarts and reschedules
  
• Performance overhead may arise from storage abstraction layers
  
• Networking complexity can affect latency-sensitive workloads
  
• Security risks increase if secrets or volumes aren’t properly isolated

Managing Stateful Applications and Persistent Storage

Unlike stateless services, databases require persistent, reliable storage. Both Docker and containerd support stateful applications, but proper configuration is key:

• Volumes: Use named volumes or external volume drivers to persist data outside the container lifecycle
  
• Bind mounts: Useful for local testing, but not ideal in production due to tight coupling with host paths
  
• Storage drivers: Choose drivers optimized for performance (e.g., overlay2 or devicemapper) based on workload needs
  
• Orchestration integration: In Kubernetes, leverage PersistentVolumeClaims (PVCs) with storage classes to dynamically provision storage

Best practice: Avoid ephemeral storage for production databases and ensure backup, snapshot, and replication strategies are container-aware.

Performance Optimization Techniques

To ensure reliable performance for containerized database workloads:

• Resource Allocation:
  
  • Pin CPU and memory resources to prevent noisy neighbor issues
    
  • Use ulimits and cgroups to control I/O and memory consumption
    
• Networking:
  
  • Prefer host or macvlan networking for low-latency connections
    
  • Avoid user-defined bridge networks for high-throughput database traffic
    
• Storage I/O:
  
  • Use high-performance volumes (e.g., NVMe-backed) for write-heavy workloads
    
  • Tune filesystem and block settings (e.g., XFS, ext4 with journaling options)
    
  • Use database-specific tuning (e.g., WAL config for PostgreSQL, innodb_flush_method for MySQL)

Pro Tip: Monitor IOPS, latency, and throughput using Prometheus/Grafana or database-native tools to continuously fine-tune performance.

Security Considerations for Containerized Databases

Securing containerized databases goes beyond basic image hardening. Here are several key areas to address:

• Rootless Containers: Running containers as non-root users helps mitigate privilege escalation risks. Tools like Podman and recent containerd updates support this out of the box.
  
• Vulnerability Scanning: Regularly scan images using tools like Trivy, Clair, or Anchore to identify outdated packages or known CVEs in base images and dependencies.
  
• Network Segmentation: Use Kubernetes Network Policies or service mesh configurations (like Istio) to isolate database traffic and restrict lateral movement.
  
• Secrets Management: Avoid hardcoding credentials in environment variables. Use Kubernetes Secrets or integrate with tools like HashiCorp Vault to manage and inject secrets securely.
  
• Read-Only Filesystems: Where possible, run containers with read-only root filesystems to reduce the surface area for tampering.

For enterprises, aligning security practices with compliance frameworks (e.g., HIPAA, PCI DSS, SOC 2) is critical. Well-architected container security not only reduces risk but also supports operational scalability across regulated industries.

Docker vs. containerd: FAQ

Does Docker still use containerd? 

Docker designed containerd, which is now a part of the CNCF, an organization that supports Kubernetes- and Docker-based deployments. Docker is still an independent project that uses containerd as its runtime. 

Can I use containerd instead of Docker?

Yes—even though containerd is a container runtime and Docker is a container engine, it’s possible. Docker is a tool that tells the container runtime, in this case, containerd, to create a container based on the container image. Although the host operating system has no concept of a container, it does provide features such as namespaces, cgroups, and file system overlays that make a container possible. This means that it would be possible to use containerd along with another component called a low-level runtime to do the work of interacting with the host operating system’s kernel to create a container and in doing so assume the functionality of Docker. 

Is containerd compatible with Docker?

Yes. containerd was designed by Docker and is completely compatible with Docker. 

Can I migrate from Docker to containerd?

Yes—you can. Google Cloud provides documentation on how to do this. 

Future Trends in Containerized Environments

WebAssembly and Containers: Converging Technologies

WebAssembly (WASM) is rapidly evolving beyond the browser and into the cloud-native ecosystem, offering a lightweight, fast-starting, and secure alternative to traditional containers. While containers are ideal for packaging and running full-fledged OS-level applications, WASM modules provide a more granular, sandboxed execution environment that can complement or, in some cases, replace containerized microservices.

Key advantages of WASM in container ecosystems include:

• Faster cold starts compared to containers—critical for serverless workloads
  
• Smaller footprint, reducing memory and CPU consumption
  
• Cross-platform support with consistent performance across environments
  
• Enhanced security via fine-grained sandboxing and capability-based access

Projects like Krustlet, Spin (Fermyon), and containerd’s WASM shim are bridging the gap, allowing Kubernetes to schedule WASM workloads alongside traditional containers. While not a replacement for stateful apps like databases (yet), WASM could reshape the edge computing model and ephemeral service execution by offloading lightweight, stateless tasks to WASM modules.

AI/ML Workloads in Containers: A Data-Driven Future

Containers have become the standard for deploying AI/ML pipelines due to their portability, reproducibility, and ease of orchestration. As AI/ML models become more complex and data-intensive, containerized environments are adapting to support these demands—particularly when tightly integrated with modern databases.

Key trends in AI/ML containerization:

• GPU Acceleration: Container runtimes now support GPU scheduling (e.g., NVIDIA Container Toolkit for Docker and Kubernetes), enabling model training and inference at scale.
  
• Modular Pipelines: ML workflows are broken into containerized stages (data prep, training, validation, inference), making them easier to manage and optimize.
  
• Database Integration:
  
  • AI/ML workloads increasingly depend on real-time, high-volume data from operational databases.
    
  • Databases like Redis, Volt Active Data, and MongoDB are used to feed feature stores, stream data into models, and store inference results.
    
  • Containerized environments allow seamless integration of these components using shared volumes, service meshes, and data pipelines.

Challenges and opportunities:

• I/O bottlenecks can emerge when training models on containerized databases without high-throughput storage
  
• Version control of models and data within containers is critical for reproducibility
  
• Data locality is becoming a priority—co-locating compute and data layers (e.g., via NVMe storage) reduces latency in model execution

Pure Storage Integration for Containerized Databases

As enterprise workloads increasingly move toward containerized environments, ensuring reliable, performant, and resilient storage for stateful applications like databases becomes mission-critical. Pure Storage offers a modern, scalable storage stack purpose-built to meet these needs through deep integration with container orchestrators and container runtimes.

Pure Storage CSI Driver: Seamless Storage Provisioning

The Pure Storage Container Storage Interface (CSI) driver provides a standardized way to integrate Pure’s block and file storage platforms—FlashArray™ and FlashBlade®—with container orchestrators like Kubernetes and runtimes like Docker and containerd.

Key capabilities:

• Dynamic provisioning of persistent volumes
  
• Support for block (FlashArray) and file (FlashBlade) workloads
  
• Snapshots and clones for dev/test and backup use cases
  
• Multi-tenancy and namespace isolation in Kubernetes environments
  
• Consistent performance with NVMe and QoS policies

For database workloads, the CSI driver enables zero-touch storage provisioning, predictable performance, and enterprise-grade resilience—whether you’re deploying PostgreSQL, MongoDB, MySQL, or NoSQL systems in production.

Portworx by Pure Storage: Container-Native Storage at Scale

Portworx is Pure Storage’s flagship Kubernetes data platform designed from the ground up for stateful containerized applications, especially databases and data services.

Why Portworx stands out for databases:

• High availability (HA): Replicate data across nodes to ensure resilience and avoid single points of failure
  
• Disaster recovery: Enable zero-RPO failover across clusters or geographies
  
• Backup and restore: PX-Backup provides application-aware, point-in-time backup for Kubernetes-native databases
  
• Storage class automation: Define storage classes per database workload with IOPS, throughput, and encryption policies
  
• Data security: Supports encryption at rest, role-based access control (RBAC), and compliance with industry standards
  
• Zero-downtime migrations: Move stateful workloads across clouds or clusters with no disruption

For example, a multi-instance Cassandra deployment using Portworx can replicate data with strong consistency guarantees, enable rolling upgrades, and instantly restore in case of node failure—all without manual intervention.

FlashArray and FlashBlade: High-Performance Storage for Data-Centric Containers

Pure’s FlashArray™ and FlashBlade® provide the performance backbone for high-throughput, low-latency database workloads running in containers:

• FlashArray delivers ultra-fast block storage, ideal for transactional databases like Oracle, PostgreSQL, MySQL, and SQL Server. It integrates seamlessly via CSI and Portworx, enabling snapshot-based backups, deduplication, and compression at scale.
  
• FlashBlade is optimized for high-performance file and object storage—perfect for analytics databases, AI/ML data lakes, and log-heavy environments (e.g., Elasticsearch, Splunk, or ClickHouse). It supports massive concurrency and throughput for container-native data platforms.

Together, they allow organizations to:

• Consolidate containerized database workloads on shared enterprise storage
  
• Scale IOPS and throughput linearly as workloads grow
  
• Simplify data protection with Pure’s unified management and snapshot architecture
  
• Support hybrid and multi-cloud strategies with consistent storage services

Pure Storage’s suite of integrations—via CSI, Portworx, and its core platforms—provides the foundation for running modern databases in containers with the same confidence, speed, and reliability you’d expect from traditional enterprise infrastructure. Whether you’re modernizing legacy databases or scaling AI/ML pipelines, Pure ensures your data stays performant, protected, and portable.

Get Container Storage as a Service

Containers, like anything else, require storage, and the more flexible and scalable your storage solution, the more advantages you’ll be able to get out of your container usage and your containerization strategies. 

Pure’s container storage as a service for hybrid cloud gives developers the agility of public cloud with the reliability and security of on-premises infrastructure, allowing them to:

• Build and update enterprise applications faster, without compromising on security, data protection, and enterprise policies.
• Easily meet scalability and reliability needs. 
• Protect containerized applications with optimized cloud-native disaster recovery and backups for all Kubernetes workloads.

Get started with Pure today. Contact us to learn more. also reliably persist data.