---
title: "Apple container vs Colima: local datastore benchmarks on an M4 Mac"
description: "A practical benchmark comparing Apple's container runtime and Colima across Redis, Postgres, ClickHouse, DuckDB, and Neo4j on one M4 Mac."
publishedAt: 2026-06-25
updatedAt: 2026-06-25
tags:
- containers
- colima
- cloudflare
- databases
- benchmarks
coverImage: /images/container-benchmark-cover-1200w.webp
coverImageWidth: 1200
coverImageHeight: 675
answerSummary:
- Apple container was faster for the long-running datastore services in this local benchmark.
- Colima stayed smoother operationally and was much faster for the short-lived DuckDB workload.
- The practical choice depends on workload shape, Docker compatibility needs, and volume behavior.
faqs:
- question: Is this Docker Desktop vs Apple container?
answer: No. Docker Desktop was not installed on this machine and was not part of the benchmark.
- question: Did Apple container win?
answer: Apple container won the long-running service workloads in this run, but Colima was faster for the short-lived DuckDB workload and smoother operationally.
- question: Why use 2 CPUs?
answer: The Colima VM was capped at 2 CPUs, so both runtimes were normalized to 2 CPUs for the shared Redis, Postgres, ClickHouse, and DuckDB run.
- question: Why was DuckDB so different?
answer: DuckDB ran as a short-lived CLI workload against a mounted workspace, while the other databases ran as long-running services over localhost TCP.
draft: false
---
import BenchmarkTable from "../../components/BenchmarkTable.astro";
Apple's new `container` CLI made me curious about something practical: should I keep using Colima for local infrastructure, or is Apple's runtime already good enough to use for real development services?
I did not want to answer that with a hello-world container. Most of my local container usage is not hello-world. It is databases, cache services, graph stores, and small analytical jobs. So I benchmarked Apple `container` against Colima across a few datastore shapes:
- Redis for cache / key-value
- Postgres for OLTP-style relational work
- ClickHouse for OLAP server work
- DuckDB for embedded analytics
- Neo4j for graph queries
The benchmark shape looked like this:
```d2 title="Benchmark shape" width=920
direction: right
runtimes: {
label: "Runtimes"
apple: "Apple container"
colima: "Colima"
}
services: {
label: "Long-running services"
redis: "Redis"
postgres: "Postgres"
clickhouse: "ClickHouse"
neo4j: "Neo4j"
}
duckdb: "DuckDB short-lived CLI"
workspace: "Mounted workspace"
client: "localhost benchmark client"
readout: "Throughput, latency, startup, setup friction"
runtimes.apple -> services: "service containers"
runtimes.colima -> services: "service containers"
runtimes.apple -> duckdb: "CLI container"
runtimes.colima -> duckdb: "CLI container"
services -> client: "TCP"
duckdb -> workspace: "bind mount"
workspace -> client: "query batch"
client -> readout
```
This is a personal benchmark on one machine, not a universal claim about container runtimes. Still, the results were useful because they were not one-dimensional.
The short version:
- Apple `container` was faster for the long-running services I tested over localhost TCP.
- Colima was easier operationally and much faster for the short-lived DuckDB workload.
- The interesting difference was not just throughput. It was also startup behavior, volume behavior, and how much runtime-specific setup each image needed.
My takeaway:
> Apple `container` is worth testing seriously for long-running local services on Apple Silicon. Colima is still the smoother Docker-compatible baseline. The right answer depends on the workload.
## What I tested
Test machine:
Docker Desktop was not installed and was not part of this test.
For Redis, Postgres, ClickHouse, and DuckDB, both runtimes were capped at:
- 2 CPUs
- 4 GiB memory
I used 2 CPUs because my Colima VM was capped at 2 CPUs. The first broad run failed when I tried to use 4 CPUs, so I normalized both runtimes to the lower available cap.
Neo4j was the first benchmark I ran, before the later 2 CPU normalization. I kept it in the article because it is a useful graph-database data point, but I treat it separately from the normalized Redis/Postgres/ClickHouse/DuckDB suite.
## Workloads
Redis, Postgres, ClickHouse, and Neo4j ran as services. The host benchmark client connected over localhost TCP.
DuckDB is different. I did not run DuckDB as a service. I ran the DuckDB CLI inside short-lived containers against a mounted workspace. That matters, because DuckDB ended up showing the opposite result from the long-running services.
## Headline results
At concurrency 4, Apple `container` was faster for every long-running service workload in this run.
DuckDB went the other direction.
That split is the main point of the benchmark. If I had only tested services, Apple would look like the clear answer. If I had only tested DuckDB, Colima would look like the clear answer. Testing both made the result more useful.
## Service concurrency detail
Each service workload ran at concurrency 1, 4, and 8. Each level ran for 10 seconds.
All final workload summaries reported zero operation errors.
Redis and Postgres showed the strongest Apple wins in the normalized suite. ClickHouse also favored Apple, but by a smaller margin. Neo4j favored Apple as well, though again, it came from the earlier graph run with a different resource cap.
## Startup and readiness
Throughput was not the only thing I measured. I also tracked pull time, detached start-command time, service readiness, and full workload command duration.
I do not treat pull time as the headline result. Some images were already warm because I reran parts of the suite while fixing benchmark issues. The clearest cold-ish Apple pull/unpack measurement in this session was ClickHouse, which took 87.784 seconds.
The more consistent lifecycle observation was this:
- Colima returned from detached `docker run -d` faster.
- Apple `container run -d` took roughly 0.7 to 0.8 seconds for these service containers.
- Once the service process was starting, readiness was similar for Redis, Postgres, and ClickHouse.
## What broke
The failures were useful. They showed the operational differences more clearly than the happy path.
### CPU caps
The first broad run requested 4 CPUs and failed under Colima:
```text
range of CPUs is from 0.01 to 2.00, as there are only 2 CPUs available
```
I changed the suite to use 2 CPUs for both runtimes. That made the comparison fairer.
### Apple `container` CPU argument parsing
Apple `container` rejected `--cpus 2.0`:
```text
The value '2.0' is invalid for '--cpus '
```
Passing `2` fixed it.
### Neo4j bind mounts
Colima worked with direct host bind mounts for Neo4j data, logs, import, and plugins.
Apple `container` did not work with the same Neo4j bind-mounted setup. The official Neo4j image tried to change ownership of `/logs` and got:
```text
Operation not permitted
```
The working Apple path used named volumes instead.
### Postgres named volumes
Postgres initially failed under Apple `container`:
```text
initdb: error: directory "/var/lib/postgresql/data" exists but is not empty
initdb: detail: It contains a lost+found directory, perhaps due to it being a mount point.
```
Apple named volumes are ext4 images, and the root contains `lost+found`. Postgres does not want to initialize directly into a non-empty data directory.
The fix was:
```text
PGDATA=/var/lib/postgresql/data/pgdata
```
### ClickHouse auth
ClickHouse required explicit credentials in this image. I set:
```text
CLICKHOUSE_DB=bench
CLICKHOUSE_USER=bench
CLICKHOUSE_PASSWORD=bench
CLICKHOUSE_DEFAULT_ACCESS_MANAGEMENT=1
```
### DuckDB invocation
The DuckDB image needed the binary invoked explicitly:
```text
duckdb /workspace/bench.duckdb
```
That was a benchmark-runner fix, not really a runtime finding.
## What Apple `container` did well
Apple's strongest result was service throughput.
Redis, Postgres, ClickHouse, and Neo4j all had higher throughput under Apple `container` in this run. The advantage was largest for Redis, Postgres, and Neo4j. ClickHouse was closer but still favored Apple.
That makes Apple `container` interesting for local development workflows where:
- the service runs for a while
- the client connects over localhost TCP
- the image works cleanly with Apple's volume model
- Docker CLI compatibility is not the main requirement
## What Colima did well
Colima was smoother.
It used the normal Docker CLI. It was easier to script. Detached service starts returned faster. Bind mounts behaved more like I expected from Docker-shaped workflows.
And DuckDB was not close: Colima was much faster for the short-lived embedded analytics job.
That makes Colima still attractive for:
- Docker-compatible local workflows
- tools that expect Docker behavior
- scripts built around `docker run`
- mounted-file workloads
- short-lived containerized commands
Colima being boring is a feature.
## What surprised me
The interesting result is not that one runtime is faster than the other. The interesting result is that workload shape changed the answer.
If I had only tested Redis and Postgres, Apple `container` would look like the obvious choice.
If I had only tested DuckDB, Colima would look like the obvious choice.
If I had only tested Neo4j, I would have seen Apple's graph-query throughput and missed the volume-model friction.
Testing several datastore shapes made the split clearer:
- long-running services favored Apple
- short-lived file-backed analytics favored Colima
- operational simplicity favored Colima
- service throughput favored Apple
That is the result I trust most from this session.
## How I would use this today
For my own local development, this does not replace Colima outright.
Colima remains my default compatibility runtime because it maps cleanly to Docker workflows and existing tooling.
Apple `container` is the runtime I would test selectively for long-running local services where:
- the image is known to work
- the volume setup is understood
- the service benefits from the throughput profile
- Docker CLI compatibility is not required
For the graph-database case specifically, both paths make sense:
- Colima for the smoother Docker-compatible path
- Apple `container` for faster query throughput, using named volumes by default
## Caveats
These are personal local tests on one Apple M4 machine with 16 GiB RAM.
This is not a production benchmark.
This is not a Docker Desktop benchmark.
This does not measure multi-day reliability, Compose workflows, Kubernetes behavior, backup/restore, memory pressure under larger datasets, or production durability.
Some pull timings were warm or partially warmed by reruns, so pull time is not the main result.
ClickHouse and DuckDB used `latest` images in this pass. That is fine for this personal test, but not ideal for a fully reproducible benchmark suite.
The Neo4j result was carried forward from the earlier graph-database run and used a different resource cap than the later Redis/Postgres/ClickHouse/DuckDB suite.
## FAQ
### Is this Docker Desktop vs Apple `container`?
No. Docker Desktop was not installed on this machine and was not part of the benchmark.
### Did Apple `container` win?
For long-running service workloads in this run, yes, Apple `container` had higher throughput.
For the short-lived DuckDB embedded workload, no. Colima was much faster.
For operational simplicity, Colima was smoother.
That is why I do not reduce the result to a single winner.
### Why use 2 CPUs?
Because my Colima VM was capped at 2 CPUs. The first broad-suite run failed when the runner requested 4 CPUs. I changed the suite to use 2 CPUs for both runtimes so Apple would not get a higher CPU cap than Colima.
### Why is Neo4j treated differently?
Neo4j was the original benchmark that started the session. It was run before the later 2 CPU normalization. I kept it in the article because it is a useful graph-database data point, but I keep it separate from the normalized datastore suite.
### Why was DuckDB so different?
DuckDB was measured as an embedded CLI workload inside short-lived containers using a mounted workspace. Redis, Postgres, ClickHouse, and Neo4j were long-running services over localhost TCP. Different shape, different result.
### Would larger datasets change the result?
Possibly. Larger datasets, longer runs, heavier write pressure, different volume modes, and memory pressure could all change the shape.
## Final read
Apple `container` looks genuinely strong for long-running local datastore services on Apple Silicon. In my tests, Redis, Postgres, ClickHouse, and Neo4j all had better throughput under Apple `container`.
Colima remains the easier operational baseline. It is Docker-compatible, predictable, and better for the short-lived DuckDB embedded workload I tested.
So I do not frame this as a replacement story.
I frame it this way:
> Apple `container` is now worth testing seriously for local services. Colima is still the compatibility baseline. The right answer depends on the workload.
That is a more useful result than a single winner.
## References
- Apple `container`: https://github.com/apple/container
- Apple Open Source `container`: https://opensource.apple.com/projects/container
- Colima: https://github.com/abiosoft/colima
- Redis image: https://hub.docker.com/_/redis
- Postgres image: https://hub.docker.com/_/postgres
- ClickHouse image: https://hub.docker.com/r/clickhouse/clickhouse-server
- DuckDB image: https://hub.docker.com/r/duckdb/duckdb
- Neo4j image: https://hub.docker.com/_/neo4j
## Disclosure
This article was written with assistance from ChatGPT/Codex based on my local benchmark session, commands, outputs, and review direction.