What is a Serverless Key-Value Database?
Serverless compute needs serverless data. Explore connectionless HTTP APIs and consumption-based pricing models.
"Serverless" usually refers to compute (Lambda, Cloud Functions). But your data needs to be serverless too.
A serverless key-value database abstracts away the concept of "instances", "clusters", or "shards". You just have an endpoint, and you send it data.
The Connection Problem
Traditional databases (Postgres, Redis) rely on persistent TCP connections.
- Stateful: The server creates a thread/process for each connection.
- Limit: You might hit
max_connections(e.g., 100).
Serverless functions are stateless and ephemeral. They might launch 1,000 concurrent executions for a spike in traffic. If each one tries to open a TCP connection, your database falls over.
HTTP is the new TCP
The defining feature of a serverless-ready database is an HTTP API.
- Connectionless: Each request is independent.
- Firewall Friendly: Works over standard port 443.
- Scalable: The load balancer handles the traffic, not the database connection pool.
Consumption-Based Pricing
The other half of "serverless" is the billing model.
- Traditional: Pay $20/month for a "server" whether you use it or not.
- Serverless: Pay $0.00 if you have 0 users. Pay more as you grow.
This aligns incentives. For dev/test environments or sporadic workloads (like a cron job that runs once a day), serverless databases are infinitely cheaper.
Use Cases
- Vercel / Netlify Functions: Backend logic for frontend deployed sites.
- Webhooks: Handling stripe events, slack bots.
- IoT: Devices sending telemetry data intermittently.
Conclusion
If your compute is serverless, your database should be too. Don't pay for idle time. Look for a key-value store that offers an HTTP API and usage-based (or flat-tier) pricing that respects your scale.
BaseKV provides both the traditional TCP interface for apps that need it, and a serverless HTTP API for modern edge functions.