Skip the API, Ship Your Database

Summary

The post describes an unexpected use for LiteFS, a distributed SQLite database: replacing service-to-service APIs with read-only database replicas. Typical APIs require anticipating access patterns; shipping the full database lets clients use SQL joins, aggregation, and windowing locally, while one-way LiteFS replication avoids chatty gossip and is simple to configure with an upstream primary hostname. Moving queries to client hardware removes shared service compute contention and the need for tenant rate limiting and timeouts, but replicas cannot handle mutations and raw schema changes create looser contracts, mitigated by backward-compatible changes and views. Data access is harder to restrict in multi-tenant databases, so per-tenant SQLite files are a suggested workaround. The approach is positioned for specific read-heavy use cases, potentially including local copies of Stripe or GitHub data, with event buses such as Kafka generating per-tenant databases.

Takeaways

1. 1

   Clients can query and join a full local database with vanilla SQL, including aggregation and windowing that the post says GraphQL does not provide as built-in capabilities.

2. 2

   Read-only replicas move query computation onto each tenant’s hardware, reducing concerns about shared resource contention, rate limiting, and query timeouts.

3. 3

   Replicas do not support mutations, and shipping raw schemas makes contract changes harder; backward-compatible schema changes and database views can help preserve compatibility.