DEV Community

Lucas Martin
Lucas Martin

Posted on

Docker Alternatives for Local Postgres Dev: A 2026 Comparison

#docker #postgres #supabase #webdev
  • Podman and Colima swap the container runtime; RAM stays ~1.4-1.6 GB because the 12 containers stay
  • PGlite drops to ~80 MB but you rebuild auth/realtime/storage yourself
  • A single-process Supabase-compatible stack (Tinbase) lands at ~100 MB with the supabase-js SDK unchanged
  • Pick by which trade-off hurts: prod parity, laptop RAM, or SDK compatibility

Docker Desktop pricing changes and RAM overhead have pushed the "Docker alternatives" conversation from niche to mainstream. For Postgres-backed local development specifically (Supabase-style stacks, Prisma + Postgres, or any full-stack app with a real DB), the choices in 2026 are richer than they were a year ago. This is a hands-on comparison of the five approaches I tested, with real numbers on RAM, boot time, and dev ergonomics.

The setup

All measurements from a 16 GB MacBook Pro M2, same test workload: a Next.js app with 12 tables, auth, and a realtime subscription. Each backend booted cold, the app started, one user created via auth, one INSERT made against a subscribed table. RAM via docker stats (container approaches) or Activity Monitor (host processes). Boot time is wall-clock from start command to the dev server successfully querying the database. Your numbers will differ; the ratios probably won't.

Approach 1: Docker Compose + Supabase (baseline)

The standard: supabase start spins up 12 containers.

  • RAM: ~1626 MB across the containers
  • Boot: 45s cold, 12s warm
  • Disk: ~2.3 GB of images 
supabase init
supabase start
Enter fullscreen mode Exit fullscreen mode

Works out of the box, mirrors prod behavior, has the whole ecosystem behind it. The RAM cost is the price of admission.

Approach 2: Podman + Supabase

Same compose file, different runtime.

  • RAM: ~1580 MB
  • Boot: 42s cold
  • Disk: ~2.3 GB 
brew install podman
podman machine init && podman machine start
DOCKER_HOST=unix:///tmp/podman.sock supabase start
Enter fullscreen mode Exit fullscreen mode

The Docker Desktop licensing question goes away, but the RAM and boot story barely moves. Podman is a "get Docker Desktop off my machine" solution, not a "make local dev faster" solution.

Approach 3: Colima + Supabase

Colima wraps Lima for a Docker-compatible daemon with a lighter host VM.

  • RAM: ~1420 MB
  • Boot: 38s cold
  • Disk: ~2.3 GB 
brew install colima docker
colima start --cpu 4 --memory 4
supabase start
Enter fullscreen mode Exit fullscreen mode

Better than Docker Desktop on RAM, still 12 containers. The savings come from a lighter VM, not a different architecture.

Approach 4: PGlite + custom auth (no containers)

PGlite is Postgres compiled to WASM, running in-process. Great for tests and prototyping, but you build the rest of the stack yourself.

  • RAM: ~80 MB
  • Boot: ~2s
  • Disk: ~50 MB 
import { PGlite } from '@electric-sql/pglite';
const db = new PGlite('./data');
await db.exec("CREATE TABLE users (...)");
Enter fullscreen mode Exit fullscreen mode

No auth, no realtime, no storage: you build or stub each. Perfect for a solo prototype where you aren't testing the auth flow. Painful the moment you need Supabase's actual features.

Approach 5: Single-process Supabase-compatible (Tinbase)

Tinbase runs Postgres semantics plus auth, storage, realtime, and edge functions as one process that speaks the supabase-js wire protocol. It's built on PGlite under the hood, started with one command, and it's young: the project itself labels it alpha, aimed at local dev, prototypes, and embedded use rather than production.

  • RAM: ~100 MB
  • Boot: ~3s cold
  • Disk: ~58 MB 
npx tinbase start
Enter fullscreen mode Exit fullscreen mode

Then in the app, no client changes:

import { createClient } from '@supabase/supabase-js';
const supabase = createClient('http://localhost:54321', LOCAL_KEY);
await supabase.auth.signUp({ email, password });
await supabase.from('todos').insert({ title: 'hi' });
Enter fullscreen mode Exit fullscreen mode

RLS policies, auth.uid(), triggers, and foreign keys behave like Postgres because underneath it is Postgres.

Summary table

Approach RAM Boot cold Disk SDK compat
Docker Supabase 1626 MB 45s 2.3 GB Native
Podman Supabase 1580 MB 42s 2.3 GB Native
Colima Supabase 1420 MB 38s 2.3 GB Native
PGlite 80 MB 2s 50 MB None (raw Postgres)
Tinbase 100 MB 3s 58 MB Native

When to pick what

  • Docker Supabase: team-shared staging, maximum prod parity, when RAM isn't your bottleneck.
  • Podman: you specifically want off Docker Desktop for licensing; everything else stays.
  • Colima: same as Podman with slightly better macOS ergonomics.
  • PGlite: unit tests, browser-side Postgres, prototypes without auth requirements.
  • Tinbase: local dev where you need Supabase's actual feature set (auth, realtime, RLS) without Docker's weight. Solo work, laptop-bound teams, workshop demos.

If prod parity is non-negotiable, stay on Docker. If your laptop is the bottleneck, the single-process end of the spectrum is dramatically cheaper for equivalent SDK compatibility.

Conclusion

The RAM delta between the two ends here (1626 MB vs 100 MB) is not a marginal optimization; it's the difference between a laptop that thermal-throttles at 11am and one that doesn't. Try the swap for a week and keep Docker Compose around for when you need it. Tinbase is open source under MIT; the repo is github.com/tinbase/tinbase if you want to read the code or the caveats first.

What's your local Postgres setup, and what's it actually costing you in RAM? Run the same five-minute measurement and drop your numbers in the comments; I'll add interesting configs to the table.

Top comments (0)