DEV Community

Cover image for Keep the Database. Close the Port.
ZedGi
ZedGi

Posted on

Keep the Database. Close the Port.

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:

  1. Where code runs — VMs, containers, functions, or the edge
  2. Where data lives — the Redis, Postgres, or MySQL estate you already run, or a new vendor
  3. 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:

  1. Compute (functions, edge, remaining VMs)
  2. Data platform (the current database, plus any new one)
  3. Connectivity (VPN, NAT, custom proxies, vendor poolers)
  4. 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

  1. 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.
  2. Close public database ports first. Scan 3306, 5432, 6379, 27017. Private segment. Jump host with MFA if a human needs a shell.
  3. Freeze accidental data migrations. Re-host only when the data platform itself is the product decision.
  4. 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.
  5. Pick one access standard. One signed HTTPS path across Workers, Lambda, Node, Python, and scripts.
  6. 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
Enter fullscreen mode Exit fullscreen mode
  • 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

Top comments (0)