Most people left Google I/O 2026 talking about Gemini.

Reasonable.

There were bigger models, better agents, deeper integrations, more autonomous workflows, and enough AI announcements to overload an entire industry for months.

But the demo I kept thinking about afterward wasn’t the flagship keynote reveal.

It was a weird little browser game called Infinite Scaler.

And honestly, I think it quietly revealed something important about where interactive software is heading next.

At First Glance, It Looked Like a Throwaway Demo

The concept sounded almost silly.

A multiplayer climbing game.
Players bounce upward through randomly generated worlds.
Every level is created from prompts submitted live by users.

That’s it.

During the demo, creators Valkyrae and CourageJD generated things like:

• cyberpunk cities
• capybaras
• spaghetti slides
• disco snails
• ships in bottles
• pets
• floating burgers
• animals with sweaters

The environments were generated dynamically through Gemini-powered pipelines while thousands of people played simultaneously. :contentReference[oaicite:0]{index=0}

On the surface, it looked like:

“Haha look, AI-generated game worlds.”

But I think the deeper implication was much more important than the demo itself.

Infinite Scaler Wasn’t Really a Game Demo

It was a prototype for generative interaction systems.

That’s the part I don’t think enough people noticed.

Traditionally, games are built around:

• predefined assets
• handcrafted environments
• static mechanics
• finite content pipelines

Even procedural generation usually operates within tightly constrained systems.

Minecraft seeds.
Roguelike maps.
No Man’s Sky terrain generation.

Still algorithmic.
Still bounded.

Infinite Scaler felt different.

Because the generation layer wasn’t only procedural.

It was conversational.

Language Became the Level Editor

That changes everything.

The game wasn’t asking players to:

• pick a map
• choose a biome
• customize presets
• browse assets

Instead, users described imagination directly.

A player types:

“a jellyfish DJ underwater rave”

The system interprets:

• semantic meaning
• style
• objects
• composition
• visual depth
• thematic relationships

Then generates a playable environment around it in real time.

That’s not traditional game interaction anymore.

That’s intent-driven generation.

And honestly, I think this is one of the clearest examples yet of AI changing interfaces at the infrastructure level instead of the feature level.

The Most Important Part Wasn’t the Graphics

It was the speed.

This entire loop happened:

• inside a browser
• at scale
• multiplayer
• with thousands of concurrent participants
• while generating entirely new content continuously

That’s technically insane.

Especially because the pipeline wasn’t simple image generation.

According to the demo:

• prompts were refined through Gemini
• assets were generated
• depth maps were created
• sprite layers were separated
• pseudo-3D environments were assembled dynamically :contentReference[oaicite:1]{index=1}

All while users kept playing.

That’s not just an AI gimmick.

That’s a real-time generative rendering pipeline operating interactively.

And I honestly think this matters more than most flashy model benchmark announcements.

This Changes the Relationship Between Players and Games

Historically, games are experiences developers create for players.

Infinite Scaler blurred that boundary.

Players became:

• participants
• co-creators
• world designers
• prompt engineers
• interaction drivers

The gameplay loop wasn’t only movement.

It was imagination itself.

That creates a fundamentally different creative dynamic.

And weirdly, this feels closer to:

• Roblox
• Minecraft
• VRChat
• modding communities
• meme culture
• TikTok creativity loops

than traditional AAA game design.

The game becomes a platform for generative expression instead of a fixed experience.

We Might Be Entering the Era of “Playable AI”

For years, AI in games mostly existed as:

• NPC behavior
• procedural enemies
• pathfinding
• recommendation systems
• balancing systems

But generative AI introduces something different entirely.

The game world itself becomes fluid.

Not just visually.

Structurally.

And Infinite Scaler accidentally showcased what that could look like at scale.

Imagine:

• multiplayer games generating live events from player conversations
• educational worlds adapting to curiosity in real time
• AI-generated social spaces
• dynamic storytelling environments
• personalized exploration systems
• infinite user-generated game loops

Suddenly, content pipelines start looking very different.

Developers May Need to Rethink What “Content” Even Means

One thing I kept thinking about after the demo:

What happens when content stops being handcrafted objects
and becomes generated possibility space instead?

That changes:

• level design
• asset pipelines
• moderation systems
• memory management
• multiplayer synchronization
• rendering optimization
• interaction design
• gameplay balancing

Traditional game development relies heavily on predictability.

Generative systems are probabilistic.

That creates entirely new engineering challenges.

Especially around:

• safety
• consistency
• coherence
• performance
• abuse prevention
• thematic stability

And honestly, I think most of the industry still underestimates how difficult this becomes at scale.

The Moderation Problem Is Massive

One line from the demo stood out to me immediately.

Before generating worlds, the hosts joked:

“As long as it’s safe for work.”

That tiny comment actually hints at one of the biggest unsolved problems in generative systems.

Because once users generate environments through language:

• moderation becomes real-time
• abuse becomes dynamic
• edge cases explode exponentially

Unlike static games, generative systems can produce combinations developers never explicitly created.

That changes moderation entirely.

And I think this is exactly why companies like Google care so much about:

• guardrails
• policy layers
• prompt filtering
• classifier systems
• constrained generation pipelines

The infrastructure challenge becomes just as important as the model itself.

Infinite Scaler Also Quietly Demonstrated AI-Native UX

This part fascinated me the most.

The interface was almost invisible.

Players weren’t navigating:

• creation panels
• asset libraries
• editing tools
• environment builders

They simply expressed ideas naturally.

The system handled translation into interaction.

That’s a huge UX shift.

Because historically, software required humans to learn system logic.

AI-native systems increasingly learn human intent instead.

And I think Infinite Scaler accidentally demonstrated that transition better than many “serious” enterprise AI demos.

This Didn’t Feel Like a Finished Product

It felt like an early glimpse of a new category.

Messy.
Experimental.
A little chaotic.

But genuinely new.

And honestly, that’s what made it interesting.

Not because it was polished.

But because it exposed a direction.

The same way early touchscreen phones felt incomplete before the industry fully understood what they would become.

I Think Google Showed More Than It Intended To

Most people probably saw Infinite Scaler as:

• a fun audience activity
• an AI showcase
• a lightweight keynote break

I think it was accidentally much bigger than that.

Because underneath the spectacle was a very important idea:

language is starting to become a real-time creative interface.

Not just for writing.
Not just for chatbots.
Not just for search.

For interactive systems themselves.

And once that happens, software stops feeling static.

It starts feeling generative.

That’s a very different future than the one most apps were originally designed for.

Microsoft, önümüzdeki hafta Office uygulamaları için yayınlayacağı güncellemeler ile kullanıcıların hareketli Copilot butonunu kapatmalarına izin verecek. Yakın zaman önce Word, Excel ve PowerPoint’e eklenen ve düzenleme alanındaki tabloların üstünde yer kapladığı için özellikle Excel kullanıcılarını kızdıran buton, önümüzdeki hafta alt bölümden yani dokümanların üstünden tamamen kaldırılabilecek.

Microsoft, Office uygulamalarındaki hareketli Copilot butonunun kaldırılmasına izin verecek yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.

Late January 2026. A developer ships a social network over a weekend. No traditional code written — just prompts, a vision, and an AI that turned ideas into a working product in days. The platform goes viral. Andrej Karpathy, OpenAI co-founder, calls it “the most incredible sci-fi takeoff-adjacent thing I have seen recently.”

Then a security researcher opens the browser’s developer tools.
Within minutes, they find an API key sitting in plain JavaScript — visible to anyone who knows how to press F12. They use it to query the production database. No login required. No special tools. Just a simple command and a coffee.

What comes back: 1.5 million API authentication tokens. 35,000 email addresses. Thousands of private messages. The entire platform — every agent, every credential, every conversation — sitting wide open.

The platform was called Moltbook. The fix, when it came, took two SQL statements.

This is not a story about a bad developer. It is a story about a gap that AI does not fill automatically — and what you can do about it before you ship.

The Illusion That Catches Everyone

A few years ago, building software required crossing a painful barrier. You had to learn syntax, frameworks, databases, APIs, Git, deployment — and break things repeatedly along the way. For most people outside tech, software engineering felt like a locked room with a very small door.

Then AI arrived.

Now someone with little traditional programming experience can build a SaaS app over a weekend, connect a database to a frontend, integrate payments, and deploy an API — all from prompts. That shift is extraordinary, and I think it is genuinely amazing. I am a vibe coder too. I understand the excitement of watching an idea move from imagination to a working product faster than ever before.

But there is a dangerous illusion forming around AI-generated software: If the app works, people assume it’s safe. Those are not the same thing.

A beautifully designed application can still expose private user data, leak API keys, allow unauthorized access, and accidentally disable database protections — all while the UI looks polished and the login flow works perfectly. Security problems live underneath visible functionality. That is exactly what happened with Moltbook.

What AI Gets Right, and What It Quietly Skips

AI is very good at helping you build the happy path — the feature works, the button responds, the API returns data, the page renders. That part is genuinely impressive.
Security lives in the unhappy paths:

• What if someone queries your database without logging in?
• What if an attacker manipulates a request from the browser?
• What if your API keys are visible in the page source?
• What if someone calls your registration endpoint ten thousand times in a loop?

Experienced developers ask these questions automatically. Not because they are smarter — but because they built the habit slowly, over years of debugging painful issues, reading post-mortems, and making mistakes in lower-stakes environments.

AI compresses the implementation timeline dramatically. It does not compress the experience required to ask the right security questions. That gap is where breaches happen.

And to be clear: this is not only a beginner problem. Even experienced developers can become overconfident when AI accelerates output speed. Because AI-generated code often looks extremely convincing. The explanations sound confident. The architecture appears plausible. The feature functions correctly.

But plausible code is not the same as safe code.

The Moltbook Breakdown: What Actually Went Wrong

Moltbook was built on Supabase — a popular, well-documented backend service that is excellent for fast development. Supabase is designed to work with a public API key exposed on the client side. That is intentional and not, by itself, a security failure.

The security failure is what you configure that key to be able to do.

Supabase ships with a feature called Row-Level Security — a database setting that ensures users can only access their own data. It is not enabled by default. You have to turn it on. And if you are vibe coding and the AI generates a working backend without you asking about security, there is a good chance that step never comes up.

At Moltbook, it didn’t.

The result: anyone with basic technical knowledge could query the entire production database — every user’s credentials, private messages, and authentication tokens — using the key sitting in plain sight on the website. Write access was also open, meaning an attacker could have edited any post on the platform without logging in.

The founder’s public statement captured the situation honestly: “I didn’t write a single line of code for Moltbook. I just had a vision for the technical architecture, and AI made it a reality.”

The AI made a working platform. It did not make a secure one.

It Is Not Just Moltbook

Six months before Moltbook, security researchers at Wiz found a critical vulnerability in Base44 — a vibe coding platform used by actual enterprises to build internal HR systems, customer databases, and knowledge bases containing sensitive employee data.

The flaw was shockingly simple: two API endpoints for registering and verifying users required no authentication whatsoever. Using only a value visible in the app’s public URL, a researcher could create a verified account inside any private enterprise application on the platform — bypassing SSO and every other access control entirely.

Here is the detail that changes the conversation: Base44 builders did not write that vulnerable endpoint. The platform did. Individual developers had no visibility into the flaw. This is the second dimension of vibe coding security risk that almost nobody talks about. The first is what AI generates when you prompt it. The second is what the platform you are building on introduces independently of your code.

Both matter. Both can be addressed.

Security in Plain English

One reason security feels intimidating is because the terminology sounds abstract and technical. Most of it isn’t. Here is a plain-English translation of the concepts that come up most often:

Security is not magic. Most of the time it is about reducing obvious mistakes, limiting damage when mistakes happen, and protecting user trust. That’s it.

The Five Things AI Consistently Misses

These are the patterns that show up repeatedly in AI-generated code — not as exotic edge cases, but as defaults. Each one comes with a practical fix.

1. API Keys Exposed in Client-Side Code
When you ask AI to connect your app to an external service, it will often put the credentials directly in the frontend code. Frontend code is public. Anyone can open the browser’s developer tools and find it. Automated scanners crawl the web looking for exactly this.

The fix: Run Gitleaks before you push code. It scans for secrets and blocks the commit if it finds any. GitHub’s built-in secret scanning does the same thing automatically on public repositories — no setup required.

2. Row-Level Security Not Enabled
This is the Moltbook failure. AI can generate a complete Supabase schema without ever enabling RLS, because RLS requires understanding your data access model — who should see what — and AI often skips that reasoning unless you ask for it explicitly.

The fix: In your Supabase dashboard, check that RLS is enabled on every table containing user data. Then write policies that define exactly who can access each row. The Supabase documentation has a beginner-friendly walkthrough that takes about twenty minutes.

-- Enable RLS on a table
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;

-- Users can only read their own records
CREATE POLICY "owner_only"
ON agents FOR SELECT
USING (auth.uid() = owner_id);

3. API Endpoints With No Authentication
AI generates routes that respond to requests. Whether it adds authentication to those routes depends on whether you asked — and whether the AI remembered your earlier requirements by the time it got to that file.

The fix: Go through every API route and ask: what happens if someone calls this without logging in? Tools like Bearer scan your codebase and flag unprotected routes for free. Better still, apply authentication at the middleware layer so every route is protected by default.

4. Secrets on the Wrong Side of the App
Many AI tools know not to hardcode secrets and will suggest environment variables. What they sometimes miss is the difference between variables available to the client (public) and variables available only to the server (private).

In Next.js, any variable prefixed with NEXT_PUBLIC_ is bundled into the client JavaScript and visible to everyone. Your OpenAI API key, Stripe secret key, and database credentials should never have that prefix.

The fix: Search your project for NEXT_PUBLIC_ and verify that nothing sensitive uses it. Server-only secrets get no prefix. Public configuration values — like your Supabase URL — can use the prefix safely, but only if RLS is properly configured.

5. No Rate Limiting
AI generates endpoints that respond to requests. It does not add rate limiting unless you ask. This means your registration endpoint, login endpoint, and data endpoints will accept unlimited requests from anyone.

At Moltbook, this allowed a single bot to create 500,000 fake accounts. The same pattern can be used to exhaust your API quota overnight and run up a bill that ends your project.

The fix: If you are on Vercel, enable rate limiting in your project’s security settings — it takes five minutes and requires no code. For Supabase, the same option exists under Project Settings. Do this before you go public.

The Mistake Almost Everyone Makes: “I’ll Secure It Later”

This mindset is understandable. When you are learning, shipping feels difficult enough already. Security can feel like an advanced topic for a future version of yourself.

The problem is that insecure architecture hardens very quickly. Once real users arrive, technical debt compounds, insecure patterns spread through the codebase, and leaked secrets cannot be unexposed. The Moltbook breach did not happen because the founder planned to fix security later. It happened because the platform went viral before that moment came.

Security is not a decorative layer added at the end. It is part of the design. That does not mean you need perfection before you launch. It means security awareness needs to begin at the same time as everything else.

Your Security Stack, Kept Simple

You do not need to become a security engineer. You need a short checklist and the discipline to run it.

Start here — these take under an hour total:

• GitHub Secret Scanning — enabled by default on public repos, catches exposed keys automatically
• Gitleaks — run it locally before pushing; blocks commits containing secrets
• Supabase RLS — enable it on every table in your dashboard; follow the docs walkthrough
• Vercel Rate Limiting — enable it in your project settings before going public
• Snyk free tier — scans your dependencies for known vulnerabilities; integrates with VS Code

When your project gets more serious:

• Semgrep — static analysis that catches insecure code patterns in CI
• CodeQL — deeper analysis integrated into your GitHub pull request workflow
• Pre-commit hooks — stop dangerous commits before they leave your machine

Think of these tools as an automated second opinion. If AI is your fast-moving junior developer, security tooling is your automated reviewer. That combination is far safer than relying on intuition alone — especially when moving quickly.

One More Thing: Ask Your AI

One of the most underused techniques in vibe coding security is simply prompting for it. Before you ship any feature that touches user data, try this:

“Review this code for security issues. Check whether any credentials are exposed in client-side code, whether database tables have Row-Level Security enabled, whether API endpoints require authentication, and whether there is rate limiting on registration and data endpoints.”

AI is quite capable of security review when asked explicitly. The problem is that it does not apply that review automatically. Make it a habit to ask. It takes thirty seconds and it will catch things.

A Fair Hearing for the Critics

The people arguing against vibe coding are not wrong. They are pointing at a real pattern: AI generates working code that skips assumptions a trained developer would never skip. Moltbook and Base44 are valid evidence of that.

But the conclusion — that people without traditional coding backgrounds should not build things — does not follow. What the evidence actually shows is that vibe coding without security awareness is dangerous. That is a different claim, and it has a different solution.

The Wiz Research team — the same team that found both breaches — put it clearly: the opportunity is not to slow down vibe coding but to elevate it. AI tools that generate Supabase backends can enable RLS by default. Deployment platforms can scan for exposed credentials automatically. The infrastructure for secure-by-default vibe coding exists. It just is not the default yet.

Until it is, the gap has to be filled by builders who know what to check — and who check it.

Before You Ship

[ ] No API keys or secrets in frontend code
[ ] Gitleaks run before pushing to the repository
[ ] Row-Level Security enabled on every database table with user data
[ ] Every API endpoint requires authentication, or is explicitly marked public
[ ] Rate limiting enabled on registration and data endpoints
[ ] NEXT_PUBLIC_ prefix checked — nothing sensitive uses it
[ ] Snyk or equivalent scanned your dependencies
[ ] Asked AI to review your code specifically for security issues
[ ] Opened the browser dev tools and checked what a stranger can see

AI is making software creation more accessible than ever. More people building means more innovation, more creativity, more diverse voices entering technology. That is a genuinely good thing.

But software engineering has always been more than generating working code. There is a layer underneath every application — trust, security, permissions, responsibility — that still belongs to the person who shipped it.

You do not need to learn everything before you build. You just need to know the layer exists, and make a habit of checking it.

The checklist is above. The tools are free. The rest is discipline. The future of software may be AI-assisted. But responsibility is still human.

Found this useful? Share it with someone who just shipped their first AI-built app. The person who needs it most is usually the one who doesn’t know they need it yet.

Every RDS instance running on-demand is paying the highest rate AWS offers. RDS reserved instance pricing cuts that rate by 29% on the lowest 1-year commitment to 69% on a 3-year All Upfront term, depending on engine and instance type. For a db.r8g.xlarge PostgreSQL Multi-AZ, the difference between on-demand and 3-year reserved is roughly $4,800/year on a single instance. Across a fleet of 20, that’s $96,000/year in avoidable spend.

The mechanics are more nuanced than EC2. The engine matters as much as the instance type. Size flexibility rules differ by engine. Oracle and SQL Server license model variants produce dramatically different reservation economics. Extended Support charges a significant cost item since March 2026 are specifically excluded from RI discounts, creating a trap for teams that reserve first and then discover their engine version is past end-of-standard-support.

What Are RDS Reserved Instances?

RDS reserved instances are a billing commitment: discounted hourly rate in exchange for a 1-year or 3-year term. You specify the engine, instance class, region, deployment type (Multi-AZ or Single-AZ), and payment option. AWS automatically applies the discount to matching running instances.

You are billed for the entire term regardless of whether the instance is running. Stop an RDS instance and you still pay the reserved rate. Terminate it; the reservation keeps billing until it expires. There are no Convertible RDS reserved instances (unlike EC2), so you cannot change engines or families after purchasing.

Payment Options

Three structures, with one constraint most guides skip: No Upfront is only available on 1-year terms. For 3-year, you must choose Partial or All Upfront.

No Upfront (1-year only): No capital outlay. Pay the reserved hourly rate for every hour of the term. Saves ~29–34% vs on-demand. Cost-positive from hour one.

Partial Upfront (1-year or 3-year): Pay a portion upfront, reduced hourly rate for the remainder. ~33–38% savings on 1-year, ~50–60% on 3-year. Most commonly chosen for 3-year terms.

All Upfront (1-year or 3-year): Full payment at purchase, zero hourly charges. Highest savings: ~34–38% for 1-year, up to 63–69% for 3-year. The difference between All Upfront and No Upfront on the same term is typically 3–10%, which becomes significant on large instance types. For a db.r8g.xlarge Oracle BYOL over 3 years, that spread is approximately $1,500–2,000 total.

Which Engines Support Size Flexibility?

Size flexibility lets your RI discount apply proportionally across instance sizes within the same family, using normalization units.

Engines with size flexibility: MySQL, MariaDB, PostgreSQL, Aurora (MySQL and PostgreSQL), Oracle BYOL.

Engines WITHOUT size flexibility: Microsoft SQL Server (all editions), Oracle License Included.

Normalization units follow the vCPU doubling pattern: micro = 0.5, small = 1, medium = 2, large = 4, xlarge = 8, 2xlarge = 16, 4xlarge = 32, 8xlarge = 64.

A db.r8g.xlarge reservation (8 units) covers two db.r8g.large instances (4 units each). A db.r8g.4xlarge reservation (32 units) fully covers four db.r8g.large instances (16 units) with 16 units remaining.

For SQL Server and Oracle LI, where size flexibility does not apply, you must match your exact instance size at purchase time. Resizing a SQL Server instance voids reservation coverage making right-sizing decisions significantly riskier before committing.

If you want to understand how AWS Savings Plans share across consolidated billing accounts, we covered it in detail here How AWS Savings Plans Share Across Consolidated Billing Accounts

Real Dollar Savings by Scenario

Percentages are less useful than dollar amounts when justifying a reservation to finance. Four realistic production scenarios:

PostgreSQL db.r8g.xlarge Multi-AZ On-demand: $0.960/hr × 8,760 hrs = $8,410/year. 1-year No Upfront: ~$5,974/year, saving $2,436 (29%). 3-year All Upfront amortized: ~$4,117/year, saving $4,293 (51%). Over 3 years on 5 such instances: $64,395 total savings.

MySQL cluster (4× db.r8g.large Single-AZ) On-demand: $8,410/year for all 4. 3-year All Upfront: ~50% savings = ~$4,205/year. 3-year total savings: ~$12,615.

SQL Server Standard (db.r8g.xlarge Multi-AZ, 2 instances) On-demand: ~$42,889/year. 1-year No Upfront: ~25% savings = $10,722/year. 3-year All Upfront: ~41% savings = $17,585/year. 3-year total savings: $52,755. High absolute rates mean even a 25% RI discount generates large absolute dollar savings.

Oracle BYOL vs License Included Oracle LI db.r8g.xlarge Multi-AZ on-demand: $3.124/hr. Oracle BYOL same spec on-demand: $0.960/hr. Migrating from LI to BYOL before reserving saves $18,957/year before any RI discount. After migration to BYOL with 3-year All Upfront: ~$0.470/hr effective rate. Total saving vs Oracle LI on-demand: $23,249/year $69,747 over 3 years. If you own Oracle licenses through an Enterprise Agreement, BYOL plus 3-year reservation is the single highest-impact RI decision in the RDS portfolio.

The Extended Support Cost Trap

Starting March 1, 2026, AWS charges $0.20 per vCPU-hour in US East for RDS Extended Support on MySQL and PostgreSQL instances past their major version end-of-standard-support date.

The critical rule: RDS reserved instance discounts do NOT apply to Extended Support charges. The surcharge is calculated separately on top of your instance rate.

Worked example db.m7g.xlarge (4 vCPUs) running MySQL 8.0 after it reaches EOL:

• Base compute with 3-year All Upfront reserved: ~$0.140/hr
• Extended Support surcharge: 4 vCPUs × $0.20/hr = $0.80/hr
• Effective hourly rate: $0.940/hr
• Compare to original on-demand without Extended Support: $0.311/hr

A team on a 3-year reserved instance ends up paying 3× the original on-demand rate purely because of the surcharge on an EOL engine.

Engine versions approaching end-of-standard-support: MySQL 8.0 (community EOL April 2026), PostgreSQL 14 (November 2026). Always verify current EOL dates before purchasing multi-year reservations on any engine version.

The right sequence: upgrade your engine version first. Then purchase reserved instances.

For spend-based flexibility as an alternative to per-instance commitments, see how Database Savings Plans compare Understanding Savings Plan Amortized Cost in AWS Cost Explorer

How to Buy RDS Reserved Instances Correctly

1. Identify stable, long-running instances. Production databases running 24/7, stable in size for 30+ days, expected to continue in the same region for 12+ months. Instances that stop regularly (dev environments, batch jobs) are poor candidates, you pay for every hour of the term.

2. Verify engine version before committing. Confirm the version has at least 18 months of standard support remaining within your reservation term. If not, the Extended Support surcharge can eliminate RI savings entirely.

3. Migrate to Graviton before reserving. Graviton3 instances (db.m7g, db.r7g, db.t4g) deliver ~15% better price-performance than equivalent x86 at the same or lower on-demand rate. Migrating from db.m5/db.r5 before reserving reduces the base rate you’re committing against, while still delivering the same 29–69% RI discount.

4. Start with 1-year No Upfront. Saves 29–34% with no capital outlay. After 12 months of confirmed stable usage, evaluate the 3-year term. The incremental savings from extending to 3-year All Upfront; an additional 15–35 percentage points depending on the engine, justify careful analysis before each renewal.

5. Use size flexibility to right-size without risk. For MySQL, PostgreSQL, MariaDB, Aurora, and Oracle BYOL, buy reservations at the instance family level. A db.r8g family reservation automatically covers size changes up or down within that family, removing the capacity planning rigidity that makes SQL Server and Oracle LI reservations significantly more risky.

Automating RDS RI Management with Usage.ai

Managing RDS reserved instances across a fleet of 20–50 instances requires constant tracking: utilization checks, term expiration alerts, new instance qualification, and engine EOL monitoring.

Usage.ai Flex Reserved Instances refresh RDS utilization analysis every 24 hours, versus AWS Cost Explorer’s 72+ hour cycle. At $6–12K/day in uncovered RDS on-demand spend for a mid-size fleet, a 3-day lag means $18–36K in unnecessary charges per review cycle. For Oracle and SQL Server where Database Savings Plans don’t apply, Usage.ai Flex Reserved Instances is the only automated optimization path. If a reservation becomes underutilized because an instance is resized or deprecated, Usage.ai provides cashback and credits on the unused portion. The fee is a percentage of realized savings only.

What’s been the trickiest part of managing RDS reserved instances at your org sizing SQL Server reservations, catching EOL engine versions before committing, or something else?

For the complete technical breakdown, read the full article here → RDS Reserved Instances: Engine-by-Engine Pricing and Commitment Guide

You definitely know that you can generate an image from text by simply feeding the prompt to Nano Banana or an equivalent. What if I tell you that you can generate a color palette out of your text, without any help from AI?

My idea is nothing complex. Just look at the HSL color model.

As you can see, to represent color, we need three numbers – hue degrees, saturation percentages, and lightness percentages. All we have to do is get those numbers out of text.
There are a few ways to do so, but one of the most common, logical, and foolproof is to create an alphabet first and then analyze character frequency second. Let me show you.
For starters, we need a text. I took Christmas from Lingua.com. If we ran character frequency analysis (as is), we would end up with something like this:

[
  {"character": " ", "count": 307},
  {"character": "e", "count": 195},
  {"character": "a", "count": 137},
  {"character": "t", "count": 134},
  {"character": "i", "count": 120},
  {"character": "s", "count": 115},
  {"character": "o", "count": 97},
  {"character": "h", "count": 94},
  {"character": "r", "count": 92},
  {"character": "n", "count": 91},
  {"character": "l", "count": 86},
  {"character": "d", "count": 79},
  {"character": "c", "count": 49},
  {"character": "m", "count": 43},
  {"character": "y", "count": 39},
  {"character": "p", "count": 35},
  {"character": ",", "count": 31},
  {"character": "g", "count": 28},
  {"character": "f", "count": 27},
  {"character": "u", "count": 21},
  {"character": "b", "count": 20},
  {"character": "w", "count": 20},
  {"character": "v", "count": 11},
  {"character": "C", "count": 10},
  {"character": ".", "count": 9},
  {"character": "S", "count": 7},
  {"character": "k", "count": 7},
  {"character": "-", "count": 6},
  {"character": "A", "count": 5},
  {"character": "(", "count": 5},
  {"character": ")", "count": 5},
  {"character": "'", "count": 5},
  {"character": "n", "count": 4},
  {"character": "j", "count": 4},
  {"character": "J", "count": 3},
  {"character": "T", "count": 2},
  {"character": "N", "count": 2},
  {"character": "x", "count": 2},
  {"character": "G", "count": 2},
  {"character": "L", "count": 2},
  {"character": """, "count": 2},
  {"character": "B", "count": 2},
  {"character": "U", "count": 1},
  {"character": "2", "count": 1},
  {"character": "5", "count": 1},
  {"character": "D", "count": 1},
  {"character": "P", "count": 1},
  {"character": "q", "count": 1},
  {"character": "/", "count": 1}
]

Unsurprisingly, the whitespace is the most frequent symbol – it’s a common thing for texts in the English language and other Western languages. If we were to process letters only (case-insensitive), the array would look like this:

[
  { "character": "e", "count": 195 },
  { "character": "a", "count": 142 },
  { "character": "t", "count": 136 },
  { "character": "s", "count": 122 },
  { "character": "i", "count": 120 },
  { "character": "o", "count": 97 },
  { "character": "h", "count": 94 },
  { "character": "n", "count": 93 },
  { "character": "r", "count": 92 },
  { "character": "l", "count": 88 },
  { "character": "d", "count": 80 },
  { "character": "c", "count": 59 },
  { "character": "m", "count": 43 },
  { "character": "y", "count": 39 },
  { "character": "p", "count": 36 },
  { "character": "g", "count": 30 },
  { "character": "f", "count": 27 },
  { "character": "b", "count": 22 },
  { "character": "u", "count": 22 },
  { "character": "w", "count": 20 },
  { "character": "v", "count": 11 },
  { "character": "j", "count": 7 },
  { "character": "k", "count": 7 },
  { "character": "x", "count": 2 },
  { "character": "q", "count": 1 }
]

Our next task is to take the HSL color wheel

Form a “string” out of symbols and “wrap” it around the wheel

By dividing the wheel into equal parts according to our “alphabet,” we got the hues. The frequency of symbols got us saturation. And luminosity has a default value – 50% for pure colors. Of course, nothing stops you from making luminosity a variable.

All right, let’s go to code:

First step, cleaning up and normalising text data according to our preferences – include or not whitespaces, numbers, etc.

    let rawChars = text.split('');

    const filteredChars = rawChars.filter(char => {

        // any whitespace
        const isSpace = /p{Separator}/u.test(char);

        // punctuation in any script
        const isPunct = /p{P}/u.test(char);

        // any numeric digit in any language
        const isDigit = /p{N}/u.test(char);

        // any letter
        const isLetter = /p{L}/u.test(char);

        // any symbol
        const isSymbol = /p{S}/u.test(char);

        if (!settings.includeWhitespace && isSpace) return false;
        if (!settings.includePunctuation && isPunct) return false;
        if (!settings.includeDigits && isDigit) return false;
        if (!settings.includeSymbols && isSymbol) return false;
        return true;
    });

    const workingText = filteredChars.join('');

Second is making a frequency table

  const charMap = {};
  filteredChars.forEach(char => {
      const key = settings.caseSensitive ? char : char.toLowerCase();
      charMap[key] = (charMap[key] || 0) + 1;
  });

Next is making auxiliary processing

  let minCodePoint = Infinity;
  let maxCodePoint = -Infinity;
  let maxFreq = 0;

  const data = entries.map(([char, count]) => {
    const preparedChar = settings.caseSensitive ? char : char.toLowerCase();
    const codepoint = preparedChar.codePointAt(0);
    if (codepoint < minCodePoint) minCodePoint = codepoint;
    if (codepoint > maxCodePoint) maxCodePoint = codepoint;
    if (count > maxFreq) maxFreq = count;
    return { char, count, codepoint };
  });

  return { 
    data, 
    minCodePoint, 
    maxCodePoint, 
    maxFreq, 
    range: (maxCodePoint - minCodePoint) || 1 
  };

Finally, HSL calculations

export const getPalette = (context) => {
  if (!context) return [];

  return context.data.map(({ char, count, codepoint }) => {
    const h = Math.round(((codepoint - context.minCodePoint) / context.range) * 360);
    const s = Math.round((count / context.maxFreq) * 100);
    const l = 50;

    return {
      char,
      count,
      h, s, l,
      hsl: `hsl(${h}, ${s}%, ${l}%)`
    };
  });
};

Anyway, let’s see what the palette for our Christmas text will look like. I made two types of data visualization for that – Tile Chart and Bar Chart.

A lot of interesting stuff is going on here. We can go the full naive approach, collect all the highest-scoring colors, and call it a day.

But here is the problem – it’s way too “loud”, too vivid and intense to be a useful color palette.

One way to overcome it will be to use the weighted clustering algorithm. Long story short:
1) we split the 360° color wheel into 30° sectors (buckets), since the standard color wheel has 12 colors, and 360/12 is 30.
2) we push each color into the corresponding bucket
3) we calculate the weight of each bucket (high saturation is high weight)
4) we calculate an average hue and average saturation for the sum of colors in each bucket
5) ???
6) PROFIT (there are no guarantees it will make a suitable palette, though, so proceed with caution)

Straight to the code:

export default function getWeightedClusters(palette: PaletteItem[]): ColorCluster[] {
    const buckets: Bucket[] = Array.from({ length: 12 }, () => ({
      totalWeight: 0,
      sumX: 0,
      sumY: 0,
      count: 0,
      originalColors: []
    }));

    palette.forEach(item => {
      // 1. Parse HSL
      const {h, s, l, char} = item;

      // 2. Calculate Weight (Favor high saturation)
      const weight = Math.pow(s, 2) + 1; // +1 to give very desaturated colors a tiny vote

      // 3. Determine Bucket (0-11)
      // We shift by 15 degrees so the primary colors are in the center of buckets
      const bucketIndex = Math.floor(((h + 15) % 360) / 30);

      // 4. Convert Hue to Vector (Radians)
      const rad = (h * Math.PI) / 180;
      const x = Math.cos(rad) * weight;
      const y = Math.sin(rad) * weight;

      // 5. Accumulate
      const b = buckets[bucketIndex];
      b.totalWeight += weight;
      b.sumX += x;
      b.sumY += y;
      b.count++;
      b.originalColors.push({ h, s, l, weight, char });
    });

    // 6. Finalize Clusters
    return buckets
      .map((b, index) => {
        if (b.count === 0) return null;

        // Convert vector average back to Hue
        let avgHue = (Math.atan2(b.sumY, b.sumX) * 180) / Math.PI;
        if (avgHue < 0) avgHue += 360;

        // Weighted average Saturation
        const avgSat = b.originalColors.reduce((acc, c) => acc + (c.s * c.weight), 0) / b.totalWeight;

        const bucketChars = b.originalColors.map(item => {return {char: item.char, color: `hsl(${item.h}, ${item.s}%, 50%)`}});

        return {
          id: index,
          representativeHue: Math.round(avgHue),
          representativeSat: Math.round(avgSat),
          strength: b.totalWeight,
          density: b.count,
          chars: bucketChars
        } as ColorCluster;
      })
      .filter((c): c is ColorCluster => c !== null);
  }

And visualization (I’ve made a color wheel and pack of cards):

Cool, huh? But it works not only with Latin alphabet-based languages, but (theoretically) supports everything.

Here is text in Japanese I took from this site, Reading Passage 3

That’s actually only a small part of what could be done. We can calculate the average hue and saturation of the text and generate a palette from just one color, for example.

You can look at the code here
You can look and play with the tool here

Thanks for coming to my TED talk. Feel free to reach me in comments or anywhere.

P.S. The cover image was created using a color palette derived from this post. R is for recursion.