Building Lean, Zero-Alloc Go REST APIs with SQLite and Multi-Stage Docker

The Case for SQLite in Modern Cloud Microservices

When building backend services for single-tenant apps or portfolio CMS architectures, provisioning separate PostgreSQL instances adds operational complexity, cold-start latency, and monthly server bills.

By pairing **Go (Golang)** with modern WAL-mode SQLite (`modernc.org/sqlite` or `mattn/go-sqlite3`), we can run an entire production API with **under 15MB of RAM** and sub-2ms query response times.

1. Enabling WAL Mode for Concurrent Reads

By default, SQLite locks the whole database during writes. Enabling **Write-Ahead Logging (WAL)** allows concurrent readers alongside a writer:

1func InitDB(dbPath string) (*sql.DB, error) {
2    db, err := sql.Open("sqlite", dbPath+"?_pragma=journal_mode(WAL)&_pragma=busy_timeout(5000)")
3    if err != nil {
4        return nil, err
5    }
6    
7    // Configure connection pool for SQLite concurrency
8    db.SetMaxOpenConns(1) // Single writer guarantees zero database locks
9    return db, nil
10}

2. Clean Layered Repository Pattern

We organize Go microservices into clean, decoupled layers: - `cmd/api/main.go`: Server boot, environment loading, and signal handling. - `internal/middleware`: CORS, JWT token verification, and fast-fail rate limiting. - `internal/repository`: Direct SQL queries with slice pre-allocation (`make([]T, 0)`) for zero-null JSON safety.

3. Multi-Stage Alpine Docker Build

Our resulting production Docker image is only **18MB in size**:

dockerfile

1# Build stage
2FROM golang:1.22-alpine AS builder
3WORKDIR /app
4COPY go.mod go.sum ./
5RUN go mod download
6COPY . .

# Minimal runtime stage FROM alpine:3.19 WORKDIR /app COPY --from=builder /app/server . EXPOSE 8080 CMD ["./server"] ```

💡 Key Architectural TakeawayResult: The Go backend running on Render handles traffic spikes effortlessly, cold-starts in 120ms, and consumes virtually zero idle CPU.