DEV Community

ZedGi
ZedGi

Posted on

How Companies Cut Serverless Costs Without Migrating Redis, Postgres, or MySQL

Serverless platforms sell a simple idea: stop paying for idle capacity. That idea is real and incomplete.

For many companies, the first wave of savings shows up in compute. The second wave of cost and delay shows up in the data plane: Redis caches, Postgres systems of record, MySQL estates, queue brokers, and private TCP services that never moved.

This post is a business-oriented field guide for teams that want serverless economics without a forced database migration. It also explains where ZedGi fits as a bring-your-own-database (BYOD) HTTPS access layer.

1. Why serverless saves money (and when it does not)

What the public cases actually show

  • Capital One reported up to 90% cost savings for some applications after moving them to AWS Lambda (official AWS case study).
  • A widely cited Coca-Cola / AWS Lambda example compared roughly 360 million yearly requests at about $12,864 on six always-on T2 Medium servers versus about $4,490 with Lambda.

Those numbers are about function hosting economics, not magic. They work when:

  • Traffic is spiky or event-driven
  • Idle time used to be expensive
  • Ops load of patching and capacity planning was high

When serverless is the wrong cost lever

If a service is near-constant load 24/7, provisioned VMs or containers can be cheaper than per-invocation pricing. Good FinOps practice is to measure before rewriting:

Workload shape Often cheaper on
Webhooks, cron bursts, campaign spikes Serverless functions
Overnight batch, queue consumers with idle gaps Serverless or scale-to-zero containers
Steady multi-core API with constant QPS Reserved VMs / right-sized containers

Takeaway for leadership: serverless is a portfolio decision, not a religion.

2. The hidden migration tax

Teams that “go serverless” often invent a second project:

  1. Move Redis to a hosted serverless Redis
  2. Move Postgres to a hosted serverless Postgres
  3. Change drivers, auth, backup, compliance, and runbooks
  4. Run dual systems during cutover
  5. Discover edge runtimes still need a special access path

That is the migration tax. It can erase year-one compute savings.

Managed serverless databases are excellent products for many teams. They are still a different trade:

  • You usually move or re-host data
  • Pricing mixes requests, storage, bandwidth, and platform limits
  • Multi-protocol stacks (Redis and Postgres and MySQL) become multi-vendor

If the strategic goal is “reduce idle compute” — not “replace our data estate” — reverse the order of operations.

3. Connectivity reality across serverless runtimes

Do not oversimplify this as “edge cannot do TCP.” Reality is more specific:

Vercel Edge runtime

The Edge runtime is HTTP-first. TCP/UDP socket APIs are not available the way they are in Node. Database access typically requires HTTP-capable drivers or a proxy.

Cloudflare Workers

Workers support outbound TCP via connect(), and Cloudflare also offers Hyperdrive for Workers-bound SQL pooling. Practical issues remain for many apps:

  • Isolates freeze between requests
  • App-managed pools (pg.Pool, long-lived sockets) go stale
  • You still need a model for Redis and multi-runtime callers

AWS Lambda / classic serverless Node

TCP works. The pain is connection storms, pool leaks when execution environments suspend, and operational glue for private networks.

VPNs

WireGuard/IPSec are strong tools for VMs. They are not something you casually run inside edge isolates for every function invocation.

Business translation: connectivity is an architecture product. Leaving every team to invent tunnels is how “serverless” becomes more expensive, not less.

4. What ZedGi is (and is not)

ZedGi is a TCP-to-HTTP proxy control plane. Your app sends signed HTTPS requests. ZedGi routes to a bridge node that opens the real TCP connection to your service, runs the command/query, and returns the result.

Your serverless / edge app
        │  HTTPS (signed + encrypted creds)
        ▼
ZedGi control plane (Cloudflare Workers + D1 + KV)
        │  short-lived bridge token
        ▼
Bridge node (Node.js, pooled TCP)
        │  native protocol
        ▼
Your Redis / Postgres / MySQL (or beta TCP services)
Enter fullscreen mode Exit fullscreen mode

Live today

  • Redis
  • Postgres
  • MySQL / MariaDB

Beta adapters

Memcached, MongoDB, RabbitMQ, NATS, MQTT, LDAP/LDAPS, SFTP, plus custom TCP on request.

What ZedGi is not

  • Not a managed database
  • Not a Prisma / native wire-protocol DATABASE_URL tunnel
  • Not “unsigned bare fetch to a public DB port”
  • Not Workers-only (unlike Hyperdrive bindings)

5. Security model that holds up in reviews

Security teams care about where passwords live.

ZedGi’s model:

  1. Client-side encryption of database credentials (AES-256 / ECIES) before they leave your app
  2. No plaintext password storage in ZedGi’s control plane stores
  3. HMAC-signed requests (API key + timestamp + nonce + body hash) to reduce tampering/replay
  4. Optional caller IP allowlist per service
  5. Bridge decrypts credentials transiently in memory only long enough to open TCP

That is a deliberate trade: ZedGi is an access path, not a password vault for your database.

6. Cost model: public numbers only

From zedgi.app pricing:

Tier What you get
Free ~30,000 requests/month (~1,000/day), no credit card, caller IP allowlist
Enterprise Custom pricing above ~10M requests/month

Compare that TCO conversation to:

  • Always-on proxy VMs + on-call
  • VPN mesh for every environment
  • Multi-vendor serverless DB bills during a multi-year dual-run

Again: industry Lambda cases prove compute leverage. ZedGi’s role is to unlock that leverage without making data migration the gate.

7. Best practices for a company serverless transition

These practices show up consistently in migration research and AWS guidance: start gradual, prefer strangler cutovers, and invest in observability early.

Checklist for engineering leadership

  1. Inventory idle spend — VMs that exist for rare peaks are prime candidates.
  2. Classify data dependencies — which paths need Redis, Postgres, MySQL, queues?
  3. Pick pilot slices — webhooks, internal tools, async jobs, AI agent backends.
  4. Keep data ownership unless migration is the actual goal.
  5. Standardize access — one HTTPS access model beats five SSH tunnels.
  6. Instrument first — latency, error budgets, cost per million invocations.
  7. Define “done” for security — where secrets live, who can call which service, IP policy.
  8. Avoid big-bang rewrites — strangler pattern keeps the cost case honest.
  9. Revisit steady-state services — not everything belongs on pure serverless.
  10. Write a exit plan — self-hosted proxy options matter for procurement.

ZedGi maps to steps 4–7: BYOD connectivity, signed access, IP allowlists, predictable per-request pricing.

8. Minimal developer path (accurate)

Install the TypeScript client:

npm install @zedgi/zedgi-client
Enter fullscreen mode Exit fullscreen mode 
import { createZedgiClient } from "@zedgi/zedgi-client";

const zedgi = createZedgiClient({
  url: "https://YOUR_SUBDOMAIN.zedgi.app",
  key: process.env.ZEDGI_KEY!,
  credentials: {
    redis: { default: { password: process.env.REDIS_PASSWORD!, db: 0 } },
    postgres: {
      default: {
        user: "app",
        password: process.env.PG_PASSWORD!,
        database: "app",
      },
    },
  },
});

// Redis over HTTPS
const redis = zedgi.redis();
await redis.set("edge:hello", "world");

// Postgres over HTTPS
const { rows } = await zedgi
  .postgres()
  .query("SELECT now() AS ts");
Enter fullscreen mode Exit fullscreen mode

The SDK handles request signing and client-side credential encryption. Python and raw HTTPS are also supported.

Docs: https://docs.zedgi.app

9. When not to use ZedGi

Be honest with stakeholders:

  • You need a native wire-protocol ORM tunnel (e.g. drop-in Prisma DATABASE_URL)
  • Your hot path is extremely chatty (thousands of round trips per user action) and every hop must be local LAN
  • You require long-lived server-push semantics that do not map well to request/response RPC for your use case
  • You are happy to fully migrate into a managed serverless database and that is the product strategy

ZedGi optimizes for ownership + multi-runtime reach + operational simplicity, not for replacing every database driver on the planet.

10. Competitive framing (tradeoffs, not trash-talk)

Approach Strength Tradeoff
Managed serverless DB (e.g. Upstash, Neon) Great DX if you adopt their data plane Migration / lock-in; multi-DB stacks multiply vendors
Cloudflare Hyperdrive Strong Workers-side SQL pooling Workers-bound; not a multi-runtime Redis+SQL BYOD layer
VPN / private network Familiar enterprise networking Heavy for edge isolates; ops overhead
In-house proxy Full control You own auth, pooling, multi-region, on-call
ZedGi BYOD Redis/Postgres/MySQL over HTTPS; client-side encrypted creds RPC hop; not a wire-protocol tunnel

Bottom line for decision-makers

  1. Serverless can cut idle compute cost — public cases from Capital One and Coca-Cola’s Lambda example show the scale of the opportunity when the workload fits.
  2. Forced database migration is a separate, expensive program.
  3. Connectivity is the silent blocker between “we want serverless” and “we shipped it.”
  4. ZedGi exists so companies can keep Redis, Postgres, and MySQL, reach them from modern runtimes over HTTPS, and start free: ~30K requests/month.

Try it: https://zedgi.app

Docs: https://docs.zedgi.app

Contact: olaoluwa@zedgi.app

Sources (industry)

  • AWS — Capital One Lambda / ECS case study (up to 90% cost savings for some apps)
  • Public recaps of the Coca-Cola / Michael Connor AWS serverless cost comparison (~$12,864 → ~$4,490 for ~360M yearly requests)
  • IBM Think — serverless pay-for-execution / reduced idle capacity model
  • Serverless migration literature on gradual/strangler approaches
  • Cloudflare / Vercel public docs and ecosystem write-ups on TCP and Edge limitations

Top comments (0)