scalability-sqlite-pool

Diagnose SQLite connection pool topology and concurrency bottlenecks in RAGAPPv3.

Updated Mar 30, 2026
One-click install
npx skills add https://github.com/ZaxbyHub/ragappv3 --skill scalability-sqlite-pool-zaxbyhub
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: scalability-sqlite-pool
Source: https://github.com/ZaxbyHub/ragappv3/tree/main/.opencode/skills/generated/scalability-sqlite-pool
Command: npx skills add https://github.com/ZaxbyHub/ragappv3 --skill scalability-sqlite-pool-zaxbyhub

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing scalability in RAGAPPv3 requires knowing where its four SQLite connection pools live, which code paths secretly open extra connections, and how many concurrent users the pools can actually support before exhaustion. ## Core Features & Use Cases - Pool Inventory: Maps all 4 SQLite connection pools (main, MemoryStore, DocumentProcessor fallback, FileWatcher fallback) with sizes and exact file/line locations. - Double-Connection Detection: Identifies the evaluate_policy vs _evaluate_policy pattern where require_vault_permission consumes 2 pool connections per request instead of 1. - Semaphore & Lock Inventory: Catalogs async locks, semaphores, and circuit breakers with capacities and timeouts. - Exhaustion Headroom Calculation: Provides a formula (floor(pool_size / connections_per_request) - concurrent_users) to quantify capacity, plus a load test checklist for 8-10+ concurrent users. - Use Case: Before load-testing a vault-scoped endpoint at 10 concurrent users, load this Skill to predict that the double-connection pattern halves effective capacity and to know exactly which dependency to fix. ## Quick Start Review the scalability of the vault-scoped API routes and calculate connection pool headroom for 10 concurrent users.

Frequently Asked Questions about scalability-sqlite-pool

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I detect double database connections per request in FastAPI?▼

Search for `.get_connection()` calls inside dependency functions, which bypass dependency injection. In this codebase, `require_vault_permission` uses the standalone `evaluate_policy` that opens its own pool connection alongside the injected one, doubling per-request consumption.

How to calculate SQLite connection pool headroom for concurrent users?▼

Use the formula floor(pool_size / connections_per_request) minus concurrent_users. With a pool of 10 and 2 connections per request, 10 concurrent users yields -5, meaning the pool is exhausted and requests block.

Why do FastAPI requests consume two SQLite pool connections?▼

This happens when a dependency calls a standalone function that opens its own connection instead of using the DI-injected one. The fix is preferring the DI generator `get_evaluate_policy` over the standalone `evaluate_policy` variant.

Does asyncio.to_thread prevent blocking with SQLite in async code?▼

Yes, wrapping synchronous SQLite calls in asyncio.to_thread releases the event loop since SQLite I/O releases the GIL during C-level execution. Services like MemoryStore use this correctly, while sync route handlers in vault_members.py block less cleanly.

What are the limits of a SQLite connection pool under concurrent load?▼

SQLite pools serialize writes and have fixed sizes, so throughput is bounded by pool_size divided by connections per request. Uncached auth queries on every request and semaphores without timeouts further reduce effective concurrency.