Benchmarks

Benchmarks

All benchmarks run on Apple M4 with PostgreSQL 15, Plex Media Server 1.41.

Concurrent Access

This is the test that matters. SQLite locks the entire database during writes — when multiple processes try to write simultaneously, most of them fail.

Real-world test: Plex + Kometa + PMM + 4 concurrent streams (7 separate processes, 15 seconds):

Metric	SQLite	PostgreSQL (TCP)
Total Writes	1,698,690	26,110
Write Errors	8,019,177 (82%)	0
Total Reads	5,014	1,125
Read Errors	0	0

• SQLite: 82% of writes fail due to database locking (~32 million errors per minute)
• PostgreSQL: zero errors, everything runs simultaneously

For rclone/Real-Debrid setups with Kometa/PMM, SQLite becomes unusable during library scans. PostgreSQL handles it without issues.

Query Latency

Query Type	SQLite	PostgreSQL (Socket)	Overhead
SELECT (PK lookup)	3.5 us	16.5 us	4.8x
INSERT (batched)	0.6 us	14.3 us	23.8x
Range Query	28.2 us	41.4 us	1.5x

PostgreSQL is slower per-query, but never locks. Smooth playback matters more than raw single-query speed.

Shim Overhead

Component	Latency	Throughput
SQL Translation (uncached)	0.28 us	3.6M/sec
SQL Translation (cached)	0.11 us	9.0M/sec
Cache Lookup	1.2 ns	815M/sec

The thread-local translation cache provides 2.5x speedup for repeated queries. Shim overhead is <1% of total query time.

Running Benchmarks

# Multi-process stress test
PLEX_PG_SOCKET=/tmp python3 scripts/benchmark_multiprocess.py

# SQLite vs PostgreSQL latency comparison
python3 tests/bench_sqlite_vs_pg.py

# Shim component micro-benchmarks
make benchmark

# Cache implementation comparison (mutex vs thread-local)
./tests/bin/bench_cache

# Library scan + playback simulation
PLEX_PG_SOCKET=/tmp python3 scripts/benchmark_plex_stress.py

# Concurrent writers test
PLEX_PG_SOCKET=/tmp python3 scripts/benchmark_locking.py