Choosing Backends

Choosing the right backend for each subsystem depends on your scale, latency, operational budget, and feature needs. Config lives in application.yaml; extras install the driver. Swap backends without rewriting callers — they depend on protocols in quadkit-contracts.

uv add "quadkit-sql[postgres]"
uv add "quadkit-cache[redis]"

Cache backends

Backend	Best for	Key trade-off
memory	Dev, single-process, low-traffic	No persistence, lost on restart, not shared across processes
redis	Production caching, rate limiting, pub/sub	Requires Redis; O(1) ops, TTL, persistence optional
memcached	Simple key-value, high throughput	No persistence, no replication, no data structures

Note

For production, redis is the recommended default. Use memory for testing and local development. Memcached is a viable choice if you only need a simple, fast cache and already operate a memcached cluster.

Search backends

Backend	Best for	Key trade-off
meilisearch	Typo-tolerant search, quick setup	Smaller ecosystem than Elasticsearch
elasticsearch	Complex queries, large-scale analytics	Heavy ops overhead, resource hungry
typesense	Low-latency instant search	Smaller community, fewer integrations
sqlite/postgres fts	Simple full-text, no extra infra	Limited relevance tuning

Tip

Start with postgres FTS if you already use PostgreSQL. Reach for Meilisearch when you need typo tolerance and instant results. Elasticsearch is extra machinery — adopt it when you need its analytics or aggregation pipeline.

Storage backends

Backend	Best for	Key trade-off
local	Dev, single-server file storage	Not distributed; no CDN, no durability guarantees
s3	General object storage, high durability	Egress costs, eventual consistency (some regions)
gcs	GCP-native, strong consistency	Slightly higher cost than S3 in some tiers
azure	Azure-native, AD integration	Tied to the Azure ecosystem
r2	Zero egress fees, S3-compatible	Newer, smaller ecosystem

Note

All cloud backends support presigned URLs for direct client uploads. R2 is especially attractive for bandwidth-heavy workloads because of zero egress fees.

Queue backends

Backend	Best for	Key trade-off
memory	Dev, testing, single-process	No durability, lost on restart
redis	Simple queues, low-latency	No delivery guarantees beyond “at most once” by default
rabbitmq	Reliable delivery, complex routing	Ops overhead, needs Erlang runtime
kafka	High-throughput, event streaming, replay	Heavy ops complexity, higher latency per message
sqs	Managed queues, AWS-native	Tied to AWS, polling cost at scale

Tip

Start with redis for most applications. Reach for RabbitMQ when you need reliable delivery and routing. Choose Kafka only when you need event streaming, replay, or high throughput (10k+ msg/s).

Database backends

SQL

Backend	Best for	Key trade-off
sqlite	Embedded, single-server, dev	No concurrent writers, limited ALTER TABLE
postgres	Production — most applications	Heavier resource footprint than SQLite
mysql	Read-heavy workloads, replication	Weaker JSON/array support than Postgres

NoSQL

Backend	Best for	Key trade-off
mongodb	Flexible schemas, document store	No joins, weaker consistency
dynamodb	Managed, auto-scaling, AWS-native	Query patterns designed upfront; cost at scale
firestore	Real-time sync, GCP-native	Limited query capabilities; tied to GCP

Note

PostgreSQL is the recommended default for most projects. It handles relational and JSON workloads well. Choose SQLite for embedded or dev use. Reserve NoSQL backends for specific use cases (high-volume time series, real-time sync, flexible schemas at scale). DynamoDB and Firestore providers exist but are not wired yet — see Compatibility.

Vector backends

Backend	Best for	Key trade-off
memory	Dev, small datasets (<10k vectors)	No persistence, lost on restart
pgvector	Postgres-native, integrated with SQL data	Limited index types, slower at scale
qdrant	High-performance vector search, filtering	Requires a separate service
pinecone	Fully managed, serverless	Vendor lock-in, egress costs

Tip

If you already use PostgreSQL, pgvector is the easiest path. For production RAG at scale, Qdrant offers a good balance of performance and self-hosting. Pinecone is ideal when you want zero ops, but watch egress costs.

Next Steps

• Compatibility — extras, driver strings, wire status
• The Ecosystem — every package
• Database guide — repositories and migrations
• Caching — stampede protection and TTL