DEV Community: Johnny Young

Looking for 10 developers to try my database platform free for 30 days — honest feedback only

Johnny Young — Mon, 15 Jun 2026 22:13:58 +0000

I'm a solo founder building YDA Cloud — a managed Postgres platform with flat-rate pricing and a database partner called RAELA.

Quick context: I work night shifts in an emergency department and build this during the day. The platform has been live since May, I run my own production applications on it, and it just went through a third-party technical audit. But I need developers outside my own bubble to use it and tell me what's actually good, what's broken, and what's missing.

What I'm offering:

30 days, full access, no credit card, no catch. I'll personally set up your project. At the end, I want honest feedback. If you'd be willing to leave a testimonial — great. If not, the feedback alone is worth it.

What YDA Cloud does:

Managed Postgres with flat-rate pricing — no egress charges, no connection surcharges, no surprise bills
RAELA: a database partner with 2,000+ executable tools (not just answers — actual schema migrations, security scans, compliance checks, monitoring setup)
SOC 2 Type II observation in progress, HIPAA wired into every tier
Security add-ons: automatic key rotation, auto-inject credentials, honeytoken leak detection
MCP server support (Team tier+)

What I need from you:

Use it for a real project. Not a hello-world. Something you'd actually put data into. After 30 days, tell me:

What worked?
What didn't?
What would make you pay for it?

That's it. No upsell, no follow-up spam, no "let's schedule a call." Just a builder asking other builders for a real read.

Interested? Drop a comment with your email or DM me. I'll create your account and send credentials directly.

ydabase.com/try-raela

Solo founder. ED clinician by night. Building the database platform I wish existed.

Your Database Bill Is Lying to You — Especially If You're Training AI

Johnny Young — Mon, 15 Jun 2026 14:32:13 +0000

The $25/mo plan that quietly becomes $400/mo when your AI workload actually runs.

The Pitch vs. The Invoice

Every managed database platform leads with the same number: a clean monthly price. $25. $50. Maybe $99 for the "Pro" tier.

What they don't lead with:

Egress charges — every byte your application reads from the database costs money leaving the network
Storage overages. your plan includes 8GB, but your training corpus just crossed 50GB
Connection surcharges — your pair generation script, your API, your dashboard, and your cron jobs each hold a connection
Compute spikes — that bulk insert job you run at 2AM triggers autoscaling you didn't ask for
Bandwidth between regions — your GPU is in us-east, your database is in us-central, and every training batch is a cross-region transfer

You find this out when the invoice arrives. Not before.

Why AI Workloads Get Hit the Hardest

Traditional web apps are read-heavy and cache-friendly. A blog with 10K daily visitors might move a few gigabytes of egress per month. The pricing model was designed for this.

AI workloads are different:

Training data is write-heavy and read-heavy simultaneously. You're generating pairs, storing them, deduplicating them, then reading them back in bulk for fine-tuning. Every stage moves data.

Embeddings multiply your storage. A 500-word document is a few kilobytes of text. Its embedding vector is 1-4KB of float arrays. Store a million documents with embeddings and your "small" dataset is suddenly 6GB of vectors alone — before your actual data.

Batch jobs are egress machines. When you pull 100K training pairs to ship to a GPU cluster for fine-tuning, that's not a web request. That's a bulk data transfer. And if your GPU provider is in a different region or cloud than your database, every byte crosses a billing boundary.

Cron jobs compound quietly. A pair generation script running every 5 minutes, writing 25 rows per call, doesn't feel expensive. But 25 rows × 12 calls/hour × 24 hours × 30 days = 216,000 writes per month from one cron. Add the reads for deduplication checks and you've got a workload that looks nothing like the "starter plan" assumptions.

The Math Nobody Shows You

Here's a real scenario. You're building a fine-tuning pipeline:

None of these show up in the "$25/mo" pricing page. All of them show up on the invoice.

What I Learned Building This

I'm not writing this theoretically. I run training pair generation pipelines that have produced over a million pairs across multiple corpora. The scripts run 24/7 on local hardware, writing directly to postgres via connection poolers.

Here's what I ran into:

Storage grew faster than expected. Training pairs aren't small when you include metadata, quality scores, deduplication hashes, and generation timestamps alongside the prompt/completion text. Two million pairs with full metadata is not a "starter tier" dataset.

Connection limits are the silent killer. When you have a pair generation script, a web dashboard, an API layer, a cron-based analytics job, and a RAELA-style AI assistant all hitting the same database, you're not at 5 connections. You're at 30-60 concurrent, and most "starter" plans cap at 20-30 before surcharging.

Egress adds up on batch operations. Pulling training data out of the database to ship to a GPU cluster — even compressed — generates egress that metered platforms charge for. If you're iterating on model training (and you will be), you're pulling that data out repeatedly.

The pricing page doesn't model your workload. Every calculator assumes web-app patterns: mostly reads, light writes, data stays in the network. AI workloads invert all of those assumptions.

What to Look For

If you're running AI workloads against a managed database, here's the checklist nobody gives you:

Ask about egress explicitly. Not "is there egress?" but "how much does it cost to pull 10GB out of the network?" If the answer is vague, the bill won't be.

Calculate your actual storage trajectory. Don't use your current dataset size. Use your projected size at 6 months of continuous generation. If you're generating 10K pairs per day, that's 1.8M pairs in 6 months. Size the plan for that, not for today.

Count your real connections. Every service, script, cron job, and dashboard is a connection. Add them up. Then add 50% because connection pooling doesn't eliminate connections — it manages them.

Check cross-region pricing. If your database and your GPU cluster aren't in the same region (they probably aren't), find out what inter-region transfer costs. This is often the largest hidden cost for training workflows.

Look for flat-rate options. Some platforms charge per-GB egress. Some charge flat-rate with generous or unlimited transfer. For AI workloads, the difference between metered and flat can be 10-20x on your monthly bill.

The Uncomfortable Truth

The managed database market prices for web apps. The AI market builds on top of managed databases. The pricing models haven't caught up, and the gap is where your budget disappears.

This isn't a knock on any specific platform. It's a structural mismatch between how databases are priced and how AI workloads actually use them. Until the pricing models evolve, the burden is on builders to model their real costs before committing to a platform.

Do the math with your actual workload. Not the demo workload. Not the tutorial workload. Your workload — the one that runs 24/7, generates millions of rows, and ships bulk data to GPUs across regions.

The $25/mo plan is real. The $25/mo bill is not.

I'm curious what others are seeing:

What's the biggest surprise you've found on a database invoice? Egress, storage, connections — what got you?
If you're running AI workloads on a managed DB, how are you handling the bulk export costs when shipping data to GPU clusters?

Drop your war stories below. The more people share what they're actually paying, the harder it gets for pricing pages to hide the real numbers.

Building AI training pipelines on postgres. Opinions from the invoice, not the pricing page.

For a look at what I'm building to solve this: ydabase.com/try-raela

I Built a Backend Platform with Flat Pricing While Working Night Shifts in an ER

Johnny Young — Sun, 14 Jun 2026 15:09:33 +0000

The Problem

Every backend-as-a-service platform bills you on usage. More rows, more storage, more functions, more money. You ship a side project, it gets some traction, and suddenly your $25/month bill is $400.

I kept seeing this happen to developers. Supabase, Firebase, Vercel — great platforms, but the pricing model punishes growth. You shouldn't have to be afraid of your own users.

So I built something different.

What I Built

YDA Cloud (https://ydabase.com) is a managed Postgres backend with flat, predictable pricing. Pick a tier, know what you pay. No overages. No surprises. Capacity warnings instead of surprise bills.

What's included in every plan:

Managed Postgres with branches and backups
Object storage with quotas
Email, OAuth, and magic link authentication
Deno edge functions with cron scheduling
Secrets vault with key rotation
Observability and monitoring
3,000+ kits in the marketplace
A built-in database partner that handles operations through natural language

Tiers run from $49 to $599/month. You pick the resources you need. You never get charged more than that.

Why Flat Pricing Works

Usage-based billing creates a misaligned incentive. The platform makes more money when your app gets more popular. Your success becomes their revenue event — and your anxiety.

Flat pricing flips that. We make money when you stay. Retention replaces extraction. We're incentivized to make the platform good enough that you never want to leave, not to meter every query you run.

The Database Partner

Most platforms bolt on a chatbot and call it AI. Our database partner is the primary interface for managing your backend.

Create tables. Configure row-level security. Deploy edge functions. Rotate secrets. Run diagnostics. All through natural language. All audit-logged. All scoped to your plan tier so she never executes an operation your plan doesn't support.

She's not an assistant. She's a working partner.

The Story Behind It

I'm not a traditional tech founder. I'm an ER nurse working full-time night shifts in a Level 1 trauma center. I built this between shifts — no funding, no team, no CS degree.

I build because the tools I needed didn't exist or cost too much or punished me for using them. YDA Cloud is what I wanted as a developer: a backend that's powerful, predictable, and doesn't nickel-and-dime me.

What I'm Looking For

Honest feedback. What's missing? What would make you switch from your current backend? What's the one feature that would make flat pricing a no-brainer?

I'm building in public and shipping fast. If flat pricing resonates with you, I'd love to hear why. If it doesn't, I'd love to hear that too.

Check it out: https://ydabase.com

If you're interested in the journey of building a software company while working in healthcare, follow me here. I'll be posting about the other products in the portfolio — cybersecurity, publishing tools, AI infrastructure, and more.