How I provision a real Postgres database in 200ms using .NET 10 and Docker (No K8s allowed)

Alvaro Lopez — Wed, 22 Jul 2026 07:58:16 +0000

If you are building integration tests for your backend, you know the drill: you need a database. You don't want a fake in-memory mock, you want the real deal. But booting a Postgres container locally or inside a GitHub Actions runner takes several seconds (sometimes minutes if the image isn't cached).

I got so annoyed by my CI pipelines hanging that I decided to build TrashDB: an API that gives you a remote, ephemeral database on demand. My hard requirement was speed. I wanted a developer to hit my API and get a fully functional database connection string in under 300 milliseconds.

Here is a look under the hood at how I architected the backend to achieve that using .NET 10 and bare-metal Docker.

1. Skipping Kubernetes Entirely

The first temptation when building an infrastructure orchestration tool is to reach for Kubernetes. But K8s is built for high availability and self-healing, not for sub-second ephemeral container provisioning. The control plane overhead alone would kill my 200ms latency budget.

Instead, I went back to basics: a bare-metal VPS running a raw Docker daemon. My .NET 10 API acts as the sole orchestrator. It talks directly to the Docker Engine API via the Unix socket (or Docker HTTP API).

2. The Architecture of a 200ms Boot

To get a container running in milliseconds, you have to ruthlessly cut corners on things you don't need for an ephemeral test environment:

Pre-pulled Images: The biggest bottleneck in container startup is pulling layers. The host machine runs a CRON job that ensures the latest postgres:alpine, redis:alpine, and chromadb images are always downloaded and cached.
No Volumes: These are throwaway databases. They don't need persistence. By bypassing volume mounts entirely, the Docker daemon doesn't have to deal with filesystem mapping or disk I/O bottlenecks during boot. It creates the container entirely in memory space.
Host Networking Bypass: Instead of setting up complex internal Docker networks or reverse proxies (like Traefik or Nginx) which add routing latency, the .NET API simply asks Docker to map the container's internal port to a random open port on the host machine.

3. The .NET 10 Orchestrator

The core logic is surprisingly simple. When an HTTP POST /v1/containers request hits the API:

Validate: The API checks the API key and requested engine.
Port Allocation: It finds a free port on the host.
Docker API Call: It sends a raw request to the local Docker socket to Create and Start a container using the pre-cached alpine image.
TTL Tagging: It applies a label to the container with an expiration timestamp.
Response: It immediately returns the host IP and the dynamically mapped port to the user.

A background BackgroundService (Worker Service) in .NET polls the Docker engine every few seconds, looking for containers whose TTL has expired, and ruthlessly sends a SIGKILL to clean them up.

Keep It Simple, Stupid (KISS)

Building TrashDB reminded me that we often over-engineer our infrastructure. By stripping away persistence, meshes, and clustering, you can push raw Docker to do incredible things incredibly fast.

If you are tired of local Testcontainers melting your CI/CD pipelines, I packaged this entire architecture into a free Alpha. You can grab an API key at trashdb.dev and get your test databases running in 200ms.

Let me know in the comments: what is the weirdest hack you've used to speed up your integration tests?

Why mocking your Vector DB in CI is a terrible idea (and a 200ms fix)

Alvaro Lopez — Tue, 14 Jul 2026 13:39:15 +0000

Over the last year, building a RAG application has become incredibly easy. But if you’ve tried to move that prototype from a Jupyter Notebook to a production-grade CI/CD pipeline, you’ve probably hit a brick wall.

Testing vector search in a GitHub Actions runner without melting the server is a logistical nightmare. When setting up pytest for an app that relies on ChromaDB or Qdrant, engineering teams usually fall into one of two traps.

Trap 1: The Mocking Illusion

You decide to mock the database client using unittest.mock. Your test asserts that collection.query() was called with the right parameters.

Why it fails: You aren't actually testing anything useful. The entire point of a RAG pipeline is semantic search, the cosine similarity thresholds, embedding dimensions, and chunk retrieval. If you mock the vector database, you are flying blind. You’ll deploy to production only to realize your distance metrics were completely wrong.

Trap 2: The DinD Heavyweight

You decide to do it right and use Testcontainers to spin up a real ChromaDB instance in your CI workflow.

Why it fails: Running Docker-in-Docker (DinD) in a GitHub runner (which gives you 7GB of RAM) is painfully slow. Pulling gigabytes of vector database images and booting the daemon consumes massive amounts of memory. Your CI pipeline goes from 45 seconds to 10 minutes, or simply crashes with an OOMKilled error.

Separating Compute from State

The problem isn’t the database; it’s where we are running it. We are forcing our CI compute runners to also act as infrastructure provisioners.

The ideal architecture for testing is separating the two. Your CI runner should do nothing but execute your test code. The database should live on a remote, isolated server, boot instantly, and destroy itself the moment the test finishes.

To solve this, I built TrashDB. It’s an orchestration API (built in .NET 10 running on bare-metal) designed to do one thing: spin up databases in 200 milliseconds and kill them.

I recently shipped a native Python SDK so you can integrate it directly into your pytest fixtures without writing complex bash teardown scripts.

import pytest
import chromadb
from trashdb import TrashDBClient

@pytest.fixture(scope="session")
def vector_db():
    client = TrashDBClient()

    # Spins up an ephemeral ChromaDB container in ~200ms
    container = client.create_container(engine="chromadb", ttl_minutes=5)

    yield container

    # Cleans up the remote server automatically
    client.terminate_container(container.id)

def test_rag_retrieval(vector_db):
    chroma_client = chromadb.HttpClient(
        host=vector_db.host, 
        port=vector_db.port
    )

    # Your actual semantic search tests go here...

By externalizing the database, your runner only executes Python code. No heavy image pulls, no OOM crashes, and you can run multiple jobs in parallel without data collisions.

I’m building TrashDB in public and it's currently in a free Alpha. If you are struggling with testing your AI apps in CI, grab an API key at trashdb.dev.

Are you currently team mock, team Testcontainers, or something else entirely? Let me know below.

DEV Community: Alvaro Lopez