DEV Community: ZedGi

ZedGi: call your own Redis, Postgres, and MySQL from serverless over HTTPS

ZedGi — Tue, 15 Sep 2026 09:39:01 +0000

Serverless runtimes are HTTP-first. Redis, Postgres, and MySQL are still TCP.

If you want a Worker, an Edge function, or a Lambda to use the database you already have, you usually get pushed into a vendor HTTP API, a VPN, or a public 5432.

ZedGi is a TCP-to-HTTP access layer instead.

Register host + port (the dashboard never takes the database password).
Call https://your-subdomain.zedgi.app/rpc with the SDK.
A Cloudflare Worker authenticates the request. A Node bridge opens pooled TCP. You get JSON back.
Credentials are encrypted in your app (X25519 + AES-256-GCM) and only decrypted in memory on the bridge. Requests are HMAC-signed with a timestamp and a single-use nonce.

TypeScript
npm install @zedgi/zedgi-client

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',
},
},
},
});

await zedgi.redis().set('hello', 'edge');
const { rows } = await zedgi.postgres().query('SELECT NOW() AS ts');

Python
pip install zedgi

import os
from zedgi import create_client

zedgi = create_client(
url="https://YOUR_SUBDOMAIN.zedgi.app",
key=os.environ["ZEDGI_KEY"],
credentials={
"redis": {"default": {"password": os.environ["REDIS_PASSWORD"], "db": 0}},
},
)

print(zedgi.redis().get("hello"))

Works from Cloudflare Workers, Vercel Edge, Deno, Bun, Node, AWS Lambda, FastAPI, and anything that can send HTTPS. Raw HTTP is documented if you are not using an SDK — it is still signed; it is not anonymous fetch.

Not a hosted database, not a Prisma wire tunnel, not Hyperdrive (Hyperdrive is excellent for Workers + Postgres/MySQL via a binding; ZedGi is multi-runtime and includes Redis).

1,000 requests/day free, then $10 / million, $5 prepaid minimum.

Docs: docs.zedgi.app Playground: zedgi.app/dashboard/playground AI agents: paste Add an agent to my app using instructions from https://zedgi.app/agents.md

Keep the Database. Close the Port.

ZedGi — Mon, 17 Aug 2026 11:00:10 +0000

Keep the Database. Close the Port.

Why 2026 security, FinOps, and edge-runtime facts all point at the access layer — not another data migration.

Infrastructure programs fail when three decisions get bundled into one ticket:

Where code runs — VMs, containers, functions, or the edge
Where data lives — the Redis, Postgres, or MySQL estate you already run, or a new vendor
How code reaches data — public ports, a VPN, a vendor HTTP API, or a signed HTTPS access path

Most “modernization” decks treat #2 as the price of #1. The 2026 public record says the expensive failures are on #3.

Keep the approved database. Close the public port. Standardize how every runtime reaches it. Do not migrate data just to reach it.

1. The open port is still the cheap attack

Production databases are not web servers. They are designed to sit behind a private network. When they do not, the rest of the security program is optional.

Intruder’s 2026 Attack Surface Management Index, drawn from more than 3,000 customer estates over the year ending March 2026, found that 26% of organizations had an internet-facing MySQL instance. MySQL was the single most common exposure. 49% of organizations exposed some risky port or service. Large firms (5,000–10,000 employees) took an average of 56 days to close exposures; small firms took 14–18 days.

That window is long enough. Wiz’s database-ransomware research describes the current playbook: internet-wide scans of 3306 (MySQL) and 5432 (PostgreSQL), a check for missing auth or a weak password, then ordinary SQL — DROP DATABASE, bulk DELETE, a new table named README_TO_RECOVER. No malware binary. No exotic exploit. The database’s own commands do the damage.

Redis is the other common miss. Wiz found Redis in 74% of cloud environments, but only 5.3% of environments had an instance on the public internet. Of those that did, 72% had at least one instance with no authentication or with weak credentials. Attackers often use that foothold for the host, not for a ransom note — which is worse, not better.

This is not a new control. CISA’s 2025 cyber-hygiene advisory (AA25-212A) restates CIS Control 9.2: close unused ports, protocols, and services. Wiz’s operational guidance is the same sentence every CISO already writes: there is rarely a legitimate reason for a production database to accept connections from arbitrary internet IPs.

If a serverless or edge rollout requires you to open 3306, 5432, or 6379 “temporarily,” the rollout is the vulnerability.

2. Credentials are still the payload

Verizon’s 2026 Data Breach Investigations Report changed the first-step ranking: 31% of breaches now start with a software vulnerability, overtaking stolen passwords as the most common initial access path. That is a real shift. It is not a reason to relax on secrets.

Read the rest of the same report. Credential abuse as the initial vector fell from 22% in the 2025 DBIR to 13%. Credentials still appeared as compromised data in 28% of breaches. 48% of breaches involved ransomware. Attackers changed where they walk in. They did not stop picking up keys once inside.

The cost side is worse than last year. IBM’s 2026 Cost of a Data Breach Report (Ponemon, 602 organizations, March 2025–February 2026) puts the global average at $4.99 million, up 12%, a record. AI-driven attacks rose 56%. One in four malicious breaches were AI-enabled; those cost $6 million, about $1 million above the average. Only 37% of breached organizations said they encrypt sensitive data both at rest and in transit. Only 34% had visibility into their cryptographic assets.

Secrets are also multiplying faster than they are rotated. GitGuardian’s State of Secrets Sprawl 2026 counted 28.65 million new hardcoded secrets in public GitHub commits in 2025 — +34% year over year, the largest jump they have recorded. AI-service secrets reached 1,275,105, up 81%. When GitGuardian retested credentials that were valid in 2022, 64% were still valid in January 2026. Internal repositories were about six times more likely to contain hardcoded secrets than public ones. About 28% of incidents originated outside git entirely — Slack, Jira, Confluence.

NIST SP 800-207 (Zero Trust) is blunt on the design implication: every data source is a resource; all communication is secured regardless of network location; access is per-session and least-privilege. That is the opposite of “paste the production password into the new SaaS form” and the opposite of “hardcode DATABASE_URL into the edge config.”

For an access layer, the procurement questions write themselves:

Where does the database password live after onboarding?
Is it stored as long-lived plaintext by a third party?
Can the caller prove freshness (timestamp, nonce) and integrity (signature) on every request?
Can you restrict which IPs may call the path?
If the access vendor is compromised, what exactly do they hold?

A design that encrypts credentials on the client, never stores the plaintext password, and signs every request is a different risk conversation from a design that asks you to become another vault of production secrets.

3. Waste is up. Do not spend the year moving data.

Flexera’s 2026 State of the Cloud Report (753 cloud decision-makers) is the FinOps counterpart to the security numbers.

Estimated wasted cloud spend ticked up to 29% — the first increase after five years of decline. Managing cloud spend remains a top challenge for 85% of respondents. 76% of large enterprises now spend more than $5 million a month on public cloud. 73% operate hybrid environments. Flexera attributes the waste reversal to AI workloads and a thicker layer of PaaS/SaaS, not to a sudden loss of FinOps interest.

That is the wrong year to invent a second program: move Redis to vendor A, Postgres to vendor B, rewrite drivers, dual-run backups, re-open compliance, and hope the compute savings survive contact with the data bill.

Managed serverless databases are good products when the goal is to re-host data. They are a different trade. If leadership’s actual goal is “stop paying for idle application servers” or “let this function reach the system of record we already run,” a data migration is optional. Treat it as optional on paper.

An honest TCO line has four entries, not one:

Compute (functions, edge, remaining VMs)
Data platform (the current database, plus any new one)
Connectivity (VPN, NAT, custom proxies, vendor poolers)
People (on-call, dual-running, incident load)

The access layer is meant to shrink #3 and keep #2 from growing unless you chose that growth.

4. The runtime map, stated accurately

Do not brief the board with “edge cannot do TCP.” That sentence is false for some runtimes and incomplete for others.

Runtime / product	What is actually true
Vercel Edge Runtime	Official network APIs are `fetch`, WebSocket, and Web standards. There is no Node `net` / general TCP socket API. HTTP-capable drivers or a proxy are the path.
Cloudflare Workers	Outbound TCP exists via `connect()`. Sockets cannot be created in global scope and shared across requests. Each open socket counts toward the isolate’s simultaneous-connection limit. App-managed pools do not survive the isolate model.
Cloudflare Hyperdrive	Connection pooling and query caching for existing Postgres or MySQL, used from Workers. It is not a multi-runtime layer and it is not Redis.
AWS Lambda / Node functions	TCP works. The remaining work is connection storms, pool leaks when environments freeze, and private-network glue.
Corporate VPN	Strong for VMs and laptops. A poor universal client for short-lived edge isolates.
Mixed org (the common case)	One-off tunnels per team become shadow infrastructure.

NIST’s Zero Trust framing is useful here too: do not treat “we are on the VPN” as the security model for every new runtime. Secure the session to the resource.

The practical standard for a company that runs Workers and Lambda and a few Node services is one HTTPS access model: signed, credential-aware, IP-restrictable, same from every runtime that can call fetch.

5. A 30-day playbook

Split the three decisions on one page. Where it runs, where data stays, how it reaches that data. If sentence two is “we migrate because serverless cannot see the database,” rewrite sentence three.
Close public database ports first. Scan 3306, 5432, 6379, 27017. Private segment. Jump host with MFA if a human needs a shell.
Freeze accidental data migrations. Re-host only when the data platform itself is the product decision.
Treat database passwords as non-human identities. Prefer client-side encryption and short-lived use. Rotate anything valid since 2022 — GitGuardian’s 64% figure exists because most teams do not.
Pick one access standard. One signed HTTPS path across Workers, Lambda, Node, Python, and scripts.
Review at 30 / 60 / 90 days. Open ports, secret findings, function spend, leftover VM spend, access-layer spend, incidents.

6. Where an HTTPS access layer fits

This is the job an access layer is for: keep Redis, Postgres, and MySQL where they already run; reach them from runtimes that speak HTTPS; do not open the database port; do not hand the password over as dashboard plaintext.

ZedGi is one implementation of that pattern. It is a TCP-to-HTTP proxy control plane, not a database.

Your serverless / edge / Node app
        │  HTTPS (HMAC-signed + client-encrypted creds)
        ▼
Control plane (Cloudflare Workers + D1 + KV)
        │  short-lived bridge token
        ▼
Bridge node (Node.js, pooled TCP)
        │  native protocol
        ▼
Your Redis / Postgres / MySQL

Live today: Redis, Postgres, MySQL / MariaDB
Beta: Memcached, MongoDB, RabbitMQ, NATS, MQTT, LDAP/LDAPS, SFTP, plus custom TCP on request
Credentials: encrypted client-side with ECIES (X25519 + AES-256-GCM) before they leave the app. ZedGi does not store the database password in plaintext. The bridge decrypts it in memory only long enough to open TCP.
Auth: every /rpc call is HMAC-signed (API key + timestamp + nonce + body hash). Optional caller IP allowlist.
Pricing (public): about 30,000 free requests/month, no card; $10 per 1M after that.

It is not a managed database. It is not Cloudflare Hyperdrive (Workers-only SQL pooling). It is not a Prisma DATABASE_URL / native wire-protocol tunnel. It is not unsigned fetch to a public port.

When not to use this pattern

You need a drop-in native driver URL for an ORM
The hot path is extremely chatty and every extra hop must be local LAN
You need long-lived server-push semantics that do not map to request/response RPC
Re-hosting onto a managed serverless database is the strategy

Decision line

Close the port because Intruder, Wiz, CISA, and CIS are describing the same cheap failure.

Stop scattering database passwords because IBM’s encryption gap and GitGuardian’s 28.65 million new secrets are the same failure in a different costume.

Do not buy a data migration to unlock functions, because Flexera’s waste line just turned up for the first time in five years.

Standardize the access path because Workers, Edge, and Lambda do not share a socket model — they share HTTPS.

That is the whole program. The product you pick for the last step is secondary. The sequence is not.

Try it: https://zedgi.app
Docs: https://docs.zedgi.app

Sources

IBM Cost of a Data Breach Report 2026 — $4.99M global average (+12%); AI-driven attacks +56%
IBM press, 29 Jul 2026 — 1 in 4 malicious breaches AI-enabled; 37% encrypt at rest and in transit
Verizon 2026 DBIR — 31% start with vulnerabilities; 48% involve ransomware; credentials as data in 28%
GitGuardian State of Secrets Sprawl 2026 — 28.65M public GitHub secrets in 2025; 64% of 2022-valid secrets still live
Flexera 2026 State of the Cloud — 29% wasted spend; first rise in five years
Intruder 2026 ASM Index — 26% exposed MySQL
Wiz, Database Ransomware
Cloudflare Hyperdrive · Workers TCP sockets
Vercel Edge Runtime APIs
CISA AA25-212A · NIST SP 800-207

Serverless Transition Best Practices for Companies (Without Forcing a Database Migration)

ZedGi — Mon, 10 Aug 2026 07:25:49 +0000

Serverless Transition Best Practices for Companies (Without Forcing a Database Migration)

Moving to serverless is not a framework choice. It is an operating-model change: how you buy capacity, how you ship slices of product, and how every runtime reaches the systems of record you already run.

This guide is a practical checklist for companies mid-transition. It is written so platform teams can hand it to product engineering without hand-waving.

Principle 0: Split three decisions

Before any migration ticket, separate:

Compute placement — VM / container / function / edge
Data ownership — keep existing Redis/Postgres/MySQL vs re-host
Access path — VPC, VPN, vendor HTTP API, or HTTPS proxy layer

Most failed programs collapse #1 and #2. Successful ones treat #3 as an explicit product.

Best practice 1 — Start with idle economics, not fashion

Serverless wins when you previously paid for capacity that sat idle.

Public anchors:

Capital One reported up to 90% cost savings for some applications moved to AWS Lambda (AWS case study).
A widely cited Coca-Cola Lambda example put ~360M yearly requests at about $4,490 vs about $12,864 on six always-on T2 Medium servers.

Also track the opposite case: steady 24/7 services often stay cheaper on right-sized provisioned capacity.

Action: label each service spiky, batch, or steady. Only the first two are default serverless candidates.

Best practice 2 — Strangle; do not big-bang

Migration research and AWS guidance converge here: extract slices, ship them on the new model, leave the monolith behind a gradual cutover.

Good first slices:

Webhooks and outbound integrations
Async jobs and queue consumers with idle gaps
Internal tools and admin APIs
AI agent / automation backends that only need request/response data access

Bad first slices:

The hottest multi-join transactional path with sub-5ms DB RTT requirements
Anything that needs exotic long-lived server-push semantics on day one

Best practice 3 — Do not pay the database migration tax by accident

Re-hosting Redis or Postgres onto a managed serverless data product can be the right strategy. It is still a data program, with dual-run cost, driver changes, backup/compliance work, and exit risk.

If leadership’s actual goal is “stop paying for idle app servers,” make data migration optional.

Action: for each pilot, write one sentence: “Data stays on X because Y.” If you cannot write Y, you are doing an accidental platform rewrite.

Best practice 4 — Design the access layer on purpose

Reality by runtime (simplified, accurate enough for planning):

Runtime	Connectivity reality
Vercel Edge	HTTP-first; no general TCP sockets like Node
Cloudflare Workers	TCP `connect()` exists; app-managed pools across isolates are fragile; Hyperdrive helps Workers-side SQL pooling
AWS Lambda	TCP works; connection pooling + private networking still need design
Mixed org (common)	One-off tunnels per team become shadow infrastructure

Action: pick one access standard for pilots. Document auth, IP policy, and failure modes.

Where ZedGi fits

ZedGi is a bring-your-own Redis / Postgres / MySQL HTTPS access layer:

App (Workers, Edge, Lambda, Node, Python, …)
  → signed HTTPS
  → ZedGi control plane (Cloudflare Workers + D1 + KV)
  → Node bridge with pooled TCP
  → your database

Credentials encrypted client-side; not stored as plaintext on ZedGi
Optional caller IP allowlist
Free ~30K requests/month
Beta adapters for additional TCP services (MongoDB, RabbitMQ, NATS, MQTT, LDAP, SFTP, …)

Not a managed database. Not a Prisma wire-protocol drop-in.

Best practice 5 — Put security gates before traffic

Edge fleets multiply secret surfaces.

Minimum gates for any access layer (including ZedGi):

Short-lived or rotatable application credentials
Request authenticity (signing / mTLS / equivalent)
Network allowlisting where applicable
Explicit “where are DB passwords stored?” answer
Audit trail for key creation and service registration

ZedGi’s model: client-side encryption of DB credentials, HMAC-signed RPC, optional IP allowlist, transient decrypt only on the bridge hop.

Best practice 6 — Instrument unit economics weekly

Track for each pilot:

Metric	Why
Cost per million invocations	Catches runaway chatter
p95 end-to-end latency	Catches geography + hop issues
Error budget / timeout rate	Catches pool and auth failures
Remaining always-on VM spend	Proves real savings
Dual-run data cost	Proves you avoided (or paid) migration tax

If cost per million climbs because the app issues 200 DB round trips per user click, fix the application shape before blaming the platform.

Best practice 7 — Keep an exit plan

Procurement and security will ask:

Can we self-host the proxy path later?
What happens if we leave?
Are we locked into a data format?

BYOD architectures score well here because the data never left your control. Prefer vendors that document self-hosted options and transparent pricing (ZedGi self-hosted / enterprise pages on the product site).

30 / 60 / 90 day plan

Days 0–30

Inventory idle VMs and spiky services
Choose one pilot + one access standard
Register Redis or Postgres on ZedGi free tier (or equivalent)
Ship one production-adjacent path with observability

Days 31–60

Expand to a second runtime (e.g. Workers + Lambda) using the same access model
Add IP allowlists and key rotation drill
Compare pilot cost vs previous always-on path

Days 61–90

Promote patterns into platform docs
Decide which steady services stay provisioned
Only then evaluate optional data re-hosting on its own ROI

When this checklist says “stop”

You need native wire-protocol ORM tunnels
Your hot path is extremely chatty and must stay on a local LAN
Migration to a managed serverless database is the strategy (not a side effect)

Honesty here protects the serverless brand inside the company.

Summary

Split compute, data ownership, and access path.
Start with spiky workloads and strangler slices.
Treat database migration as optional unless it is the goal.
Standardize secure multi-runtime access — this is where ZedGi is designed to help.
Measure unit economics; keep steady cores on provisioned capacity when cheaper.

Try ZedGi: https://zedgi.app

Docs: https://docs.zedgi.app

Contact: olaoluwa@zedgi.app

Sources

AWS Capital One Lambda case study
Public Coca-Cola / AWS Lambda cost comparison recaps
IBM serverless pay-for-execution model
Cloudflare / Vercel ecosystem materials on TCP and Edge constraints
Serverless migration literature on gradual cutover patterns
ZedGi public product, pricing, and protocol roadmap

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

ZedGi — Thu, 06 Aug 2026 15:19:06 +0000

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:

Move Redis to a hosted serverless Redis
Move Postgres to a hosted serverless Postgres
Change drivers, auth, backup, compliance, and runbooks
Run dual systems during cutover
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)

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:

Client-side encryption of database credentials (AES-256 / ECIES) before they leave your app
No plaintext password storage in ZedGi’s control plane stores
HMAC-signed requests (API key + timestamp + nonce + body hash) to reduce tampering/replay
Optional caller IP allowlist per service
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

Inventory idle spend — VMs that exist for rare peaks are prime candidates.
Classify data dependencies — which paths need Redis, Postgres, MySQL, queues?
Pick pilot slices — webhooks, internal tools, async jobs, AI agent backends.
Keep data ownership unless migration is the actual goal.
Standardize access — one HTTPS access model beats five SSH tunnels.
Instrument first — latency, error budgets, cost per million invocations.
Define “done” for security — where secrets live, who can call which service, IP policy.
Avoid big-bang rewrites — strangler pattern keeps the cost case honest.
Revisit steady-state services — not everything belongs on pure serverless.
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

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");

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

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.
Forced database migration is a separate, expensive program.
Connectivity is the silent blocker between “we want serverless” and “we shipped it.”
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