Compare cold starts and p99 latency for Neon, Turso, and MotherDuck in 2026. Get performance benchmarks and configuration commands. Essential for architects.
What Cold Starts Actually Cost You
For serverless SQL engines, cold start is the delay between an idle connection and the first query returning results. When a compute node has scaled to zero, the platform has to provision or resume it before any work happens. That gap shows up as tail latency on the exact requests users notice most: the first page load after a quiet period, a scheduled job kicking off, a webhook firing after hours of silence.
Neon, Turso, and MotherDuck each make a different bet on this problem. Neon separates storage from compute and can suspend the compute layer entirely, so cold start reflects how fast it resumes a Postgres endpoint. Turso pushes SQLite-derived databases close to the edge, trading a heavy central compute tier for many small replicas. MotherDuck builds on DuckDB's analytical engine, where the first query may also warm a working set for column-oriented scans. Knowing which model you are buying into matters more than any single headline number.
Why p99 Is the Number to Watch
Average latency hides the failures that erode trust. A median query time can look excellent while one request in a hundred stalls long enough to time out a downstream call. p99 latency captures that slow tail, and it is where cold starts, connection setup, and cross-region hops accumulate. When you compare these engines, hold p99 next to the median: a small gap means predictable behavior, a large gap means occasional pain that load tests running against warm connections will never reveal.
Measure p99 under conditions that match production. Include the idle periods that trigger scale-to-zero, run from the region your users actually sit in, and use realistic query shapes rather than a bare SELECT 1. An analytical scan on MotherDuck and a point lookup on Turso stress completely different paths, so a single benchmark query will mislead you.
Configuration Levers That Move Latency
Most of the tail latency you can control comes down to a few settings. Before comparing platforms, make sure you are comparing them tuned the same way:
- Scale-to-zero timeout: lengthening the idle window keeps compute warm and trades cost for fewer cold starts.
- Connection pooling: a pooler in front of the engine amortizes handshake and auth cost across requests.
- Region and replica placement: co-locate the database with your compute, and for edge engines put a replica near read traffic.
- Prewarming: a lightweight scheduled ping can keep an endpoint resident during expected traffic.
Use each platform's CLI to pin these down and record the exact commands alongside your results, so a benchmark stays reproducible when someone revisits it later.
Choosing for Your Workload
Match the engine to the access pattern rather than the marketing. Transactional apps with frequent small reads and writes favor a Postgres-compatible surface or edge-replicated SQLite, where connection cost and locality dominate. Analytical workloads scanning large columnar data favor an engine built for that, where the first query pays a warm-up but subsequent aggregations stay fast.
The practical path is to prototype the two or three candidates that fit your model, run the same p99 measurement against each with cold starts included, and decide with your own numbers. A cheat sheet points you at the right levers; your workload decides which engine wins.