Database Performance — Vibe Coding Benchmarks

Two of the six platforms we tested default to SQLite — a single file on disk, no connection pooling, one writer at a time. That works in a demo. It does not work when your app has 50 users saving data simultaneously. We ran a standard SELECT with a JOIN across two indexed tables (~10K rows each) at increasing connection counts.

Database Infrastructure

Platform	Database Type	Connection Pooling	Max Connections

Query Latency at 100 Concurrent Connections

p50 and p95 latency in milliseconds. Platforms limited to 1 connection omitted. Lower is better.

Latency Scaling (p95)

How p95 latency changes as concurrent connections increase. Flat is good. Exponential is trouble.

Raw Data

Platform	1 conn p50	1 conn p95	10 conn p50	10 conn p95	50 conn p50	50 conn p95	100 conn p50	100 conn p95

The SQLite problem

SQLite is an outstanding embedded database. For desktop apps, mobile apps, and single-user tools, it's often the right choice. But vibe coding platforms that default to SQLite are making an infrastructure decision that limits every app built on them.

The issue is concurrency. SQLite uses file-level locking. One writer at a time. If two users submit a form at the same instant, one waits. With 50 concurrent users, the write queue becomes the bottleneck. With 100, the app is effectively single-threaded for writes.

Postgres (used by OpenKBS, v0, and Lovable via Supabase) handles concurrent connections natively. Connection pooling keeps overhead low. The performance difference at 100 connections isn't incremental — it's the difference between a working product and a locked file handle.

Methodology note

The test query was a SELECT with an INNER JOIN across two tables with ~10K rows each, both with indexed primary keys. Connection counts represent simultaneous database connections running the same query in parallel. Platforms using SQLite were tested at 1 connection (their maximum for concurrent writes). Full methodology →