These past 3-4 days were supposed to be simple: just keep writing blog posts and building projects. Instead, I went down a deep rabbit hole learning SQLite, completely rebuilding this blog, setting up production-grade backup systems, and launching a whole new project. But honestly? These were some of the most exciting days of my coding journey so far.
The Database Revelation
Here's the thing about databases: I thought I knew what I needed.
My background is WordPress and web creation. When I started learning vibe coding around November 2024, I jumped straight into PostgreSQL because that's what everyone said was "the best database." Every tutorial, every guide, every developer I asked said PostgreSQL was the industry standard.
So I used PostgreSQL for everything. Every single project from day one.
Then last month, I stumbled across Pieter Levels' work. If you don't know him, he's the guy behind Nomad List, Remote OK, and a dozen other successful indie projects. He builds everything lean and clean - no Docker (too much overhead), no complicated setups, just simple solutions that work.
And he uses SQLite for almost everything.
Wait, what? SQLite?
I always thought SQLite was just... basic. The training-wheels database you use before graduating to "real" databases like PostgreSQL or MySQL. But after researching for a few days and asking Claude about it, I learned something important:
For most projects, SQLite isn't just good enough - it's actually better.
The Wake-Up Call: My Blog's Markdown Problem
When I built this blog, I kept it simple: markdown files for content, committed to Git, deployed to Cloudflare Pages. Clean. Static. Fast.
It worked great... until I started thinking long-term.
Here's what I realized:
- Every new blog post = another markdown file committed to Git
- Git isn't designed for thousands of content files
- The repository size would keep growing forever
- Build times would eventually become miserable
- I'd probably hit GitHub or Cloudflare Pages limits eventually
Sure, it might take a while to hit those limits. But here's the thing: I'm not planning to build just this one blog.
My goal is to build hundreds, maybe thousands of projects over my lifetime. If every content-heavy project uses the markdown-in-Git approach, I'm setting myself up for scalability problems across dozens of sites.
So I started researching databases. Specifically: what database do I actually need for a simple blog?
PostgreSQL vs SQLite: The Honest Comparison
I asked Claude to break down the actual resource usage difference between PostgreSQL and SQLite for a typical blog scenario.
The answer shocked me:
Memory usage: PostgreSQL uses 10-40x more RAM than SQLite.
For a simple blog with a few thousand posts and occasional traffic:
- PostgreSQL: 50-200MB RAM baseline (just sitting idle)
- SQLite: 1-5MB RAM (only loads what it needs)
For my VPS server running multiple projects, that difference is huge. With PostgreSQL, I might fit 3-5 projects on a single server. With SQLite, I could run 20-30 projects on the same hardware.
Cost difference over time:
- 1 project: Doesn't matter much
- 10 projects: PostgreSQL needs 2-3x more server resources
- 100 projects: PostgreSQL would cost literally thousands more per month in hosting
When I asked Claude "when should I actually use PostgreSQL over SQLite?", the answer was clear:
Use PostgreSQL when you have:
- Heavy concurrent writes (hundreds of users editing data simultaneously)
- Complex relationships requiring advanced queries
- Need for horizontal scaling across multiple database servers
- Teams of developers working on the same database
Use SQLite when you have:
- Read-heavy workloads (blogs, documentation sites, landing pages)
- Single-server deployments
- Moderate traffic (SQLite easily handles 100k+ requests/day)
- Projects where simplicity and cost-efficiency matter
For a personal blog? SQLite is perfect. For most of the projects I'm planning to build? SQLite is perfect.
Decision made: Time to learn SQLite.
The Migration: Rebuilding This Blog
Once I committed to SQLite, I tried to retrofit it into my existing static blog setup.
That was a mistake.
I spent half a day trying to integrate SQLite into a codebase designed for static markdown files. The architecture just didn't fit. I was fighting the framework instead of working with it.
So I made a call: Rebuild the entire blog from scratch.
I know what you're thinking: "You rebuilt your whole blog just to switch databases?"
Yes. And honestly? It was faster and cleaner than trying to migrate the old codebase.
Here's what I did:
- Fresh Next.js installation
- Set up SQLite database with proper schema
- Migrated existing blog posts from markdown to database records
- Rebuilt the frontend (cleaner code this time)
- Deployed to my VPS instead of Cloudflare Pages
Time estimate: I thought it would take 2-3 days. It took about 6 hours.
The rebuild was cleaner, simpler, and way easier than frankensteining SQLite into my old static setup. Plus I got to fix all the little things that were bugging me about the original design.
The Content Management Revelation
Here's something that completely changed my perspective just a few days ago.
My previous understanding was this: if I need to upload or create new content (like blog posts) for a website, I'd need both a database AND a UI interface (or CMS) for content creation. You know, like WordPress's admin panel or a custom-built content management system.
That's why I initially chose markdown files for this blog - I didn't want to spend weeks building a CMS interface. Building admin panels, authentication, forms, validation... it's a massive time sink for a solo developer.
Then I realized something obvious (but somehow new to me): I can manage content directly through the database.
Wait, what? I can just:
- Use a database GUI like DBeaver to create/edit/delete blog posts
- Write SQL scripts directly on the VPS server for bulk operations
- Skip building an entire CMS interface altogether
This changed everything.
Suddenly, managing content isn't a frontend problem anymore. I can open DBeaver, connect to my SQLite database, and edit blog posts like I'm editing a spreadsheet. Need to add a new post? Insert a new row. Need to update metadata? Edit the fields directly. Need to bulk update tags? Run a SQL script.
No login screens. No form builders. No admin panel to maintain.
For a solo developer building multiple projects, this is huge.
Instead of spending 10-20 hours building a CMS for each content-heavy project, I can:
- Design a good database schema
- Use DBeaver or direct SQL for content management
- Ship the project
Does this work for client projects or sites with non-technical editors? No, of course not. Those projects still need proper CMS interfaces.
But for my own projects? For indie hacker stuff where I'm the only person touching the content? Managing everything through DBeaver or SQL scripts is perfect.
One less thing to build. One less thing to maintain. One less surface area for bugs.
Hosting: Cloudflare Pages → VPS + SQLite
Last time I wrote about hosting, I decided to stick with Cloudflare Pages because it was free, fast, and had zero maintenance.
But that was for a static site. With SQLite, I needed a server running Node.js to query the database. Cloudflare Pages doesn't support that (they have D1 for databases, but that's a different thing).
So I moved to a VPS server on Hetzner (~$5/month).
What I gained:
- Full control over the stack
- Can run SQLite databases
- Can host multiple projects on one server
- No vendor lock-in to Cloudflare's ecosystem
What I lost:
- ...honestly, nothing important
Setting up Nginx, SSL certificates, and deployment was surprisingly straightforward. Claude Code walked me through every step. Within an hour I had:
- Nginx configured with proper caching
- SSL via Let's Encrypt (auto-renewal)
- PM2 running the Next.js app
- SQLite database humming along
And here's the kicker: the resource usage is tiny. My blog uses about 50MB of RAM total. With SQLite instead of PostgreSQL, I could easily run 10-15 blogs on a $5/month VPS.
The math is beautiful.
Learning Backups the Hard Way
Once I had my blog running on a VPS with SQLite, I realized something important: I had no backup strategy.
For the past 2-3 months since I started using VPS hosting, I just relied on Hetzner's backup add-on service (20% of the server cost, so about $1/month for my server). That backs up the entire server snapshot.
But what if I accidentally delete a database table? Or push broken code that corrupts data? Restoring a full server snapshot for a small mistake feels like overkill.
I needed application-level backups too.
So I asked Claude about backup best practices. After a long conversation about the 3-2-1 backup rule, retention policies, and disaster recovery strategies, here's what I landed on:
Backup Strategy:
- Daily backups: Full site + database
- Weekly backups: Verification of backup integrity
- Monthly backups: Test restore to staging environment
Retention:
- 7 daily backups
- 4 weekly backups
- 12 monthly backups
Storage locations:
- Local (server disk) for fast recovery
- AWS S3 (external cloud) for disaster scenarios
Security:
- All backups encrypted with GPG before storage
- Separate AWS IAM user with minimal S3 permissions
- Automated integrity checks
Then I had Claude Code implement it for me. I gave it this prompt:
Configure and set up the backup for the project 'var/www/whatshouldibuildtoday' with the following backup strategy:
- Daily: Full website + database backups → Encrypted (GPG) → Local + AWS S3
- Weekly: Verification of backup integrity
- Monthly: Test restore to staging environment
- Retention: 7 daily, 4 weekly, 12 monthly
- Cron jobs scheduled offset 15 min from other projects
Implement best practices and security best practices.
Claude set up:
- Automated cron jobs for daily/weekly/monthly tasks
- GPG encryption for all backups
- AWS S3 sync with proper IAM permissions
- Backup rotation based on retention policy
- Integrity verification scripts
Setup time per project: 15-30 minutes (mostly just watching Claude Code do its thing)
Now I sleep better knowing I have both server-level snapshots AND application-level backups, stored both locally and off-site.
Side note: If you're new to AWS S3 like I was, you need to:
- Create an S3 bucket
- Create an IAM policy (defines permissions)
- Create an IAM user (for programmatic access)
- Generate access keys
- Configure AWS CLI on your VPS
Sounds complicated, but I just asked Claude and Perplexity to walk me through each step. Took maybe 20 minutes total. Maybe I'll write up my full SOP for this later.
Building VibecodingResources.net
While I was rebuilding my blog and learning all this database/backup stuff, I kept getting the same questions from non-developer friends:
- "Where do I learn vibe coding?"
- "What tools do I need?"
- "Who should I follow?"
I'd been answering these questions one-by-one in DMs and comments. Then I realized: why not just build a resource site?
So I built vibecodingresources.net.
It's a curated collection of tools, courses, people, and resources for learning AI-assisted development. Everything someone needs to get started with vibe coding in one place:
- Tools: AI code editors, assistants, platforms
- Courses: Structured learning paths
- People: X/Twitter accounts worth following
- YouTube: Video tutorials and walkthroughs
- Blogs: Technical articles and strategies
I built it specifically for non-developers who want to learn vibe coding but don't know where to start. No gatekeeping, no assumptions of prior knowledge, just "here are the tools and resources that actually matter."
Tech stack: Next.js + Tailwind + SQLite + Hetzner VPS
Same stack as this blog. Took about 4-5 hours to build from scratch (thank you Claude Code).
The beautiful part? Because I'm using SQLite, I can run both this blog AND vibecodingresources.net on the same $5/month VPS with room to spare.
The Fundamentals Checklist
After these past few days, I feel like I finally have all the fundamental pieces in place to build the projects I want to build:
Frontend: Next.js + Tailwind + Shadcn UI
Backend: Node.js
Database: SQLite (or PostgreSQL for complex projects)
File Storage: Cloudflare R2 (zero egress fees)
Hosting: Hetzner VPS
Backups: Local + AWS S3 (encrypted, automated)
AI Assistance: Claude Code
I'm not saying I've mastered all of these. But I understand them well enough to build real projects without constantly hitting blockers.
For someone coming from a WordPress background who started learning to code with AI just a few months ago, that feels like a huge milestone.
The Wins
Let me break down what actually happened these past 3-4 days:
What I learned:
- SQLite is perfect for most projects (and 10-40x more resource-efficient than PostgreSQL)
- Rebuilding from scratch is often faster than retrofitting
- Backup strategies aren't optional - they're essential
- VPS hosting is cheaper than I thought when you optimize resource usage
- You don't need to build a CMS - database GUIs like DBeaver work perfectly for solo projects
What I built:
- Migrated this blog from static markdown to SQLite database
- Moved hosting from Cloudflare Pages to Hetzner VPS
- Implemented production-grade backup system (local + S3, encrypted, automated)
- Launched vibecodingresources.net as a learning hub for vibe coding
What it costs:
- $5/month Hetzner VPS (runs both sites)
- $0.50/month AWS S3 (backup storage)
- Total: $5.50/month for both production sites with full backups
Compare that to running two sites with PostgreSQL databases and managed backups on typical hosting... I'd easily be paying $20-40/month.
What's Next?
Now that I have the fundamentals down, I'm ready to start building the actual projects I've been planning.
No more infrastructure rabbit holes. No more "I should learn this first" detours. Just building.
What project am I building next? Still deciding. But whatever it is, it'll run on SQLite, get backed up to S3, and probably cost less than a coffee per month to operate.
To be continued.
Stack: Next.js, SQLite, Hetzner VPS, Cloudflare R2, AWS S3
Hosting: Hetzner VPS (~$5/month)
Projects launched: 2 (this blog + vibecodingresources.net)
Time spent learning: 3-4 days
Database migrations completed: 1 (markdown → SQLite)
Backup strategy implemented: Daily/weekly/monthly with 7/4/12 retention
RAM usage for both sites: ~100MB total (would be 400-800MB with PostgreSQL)
Lessons learned: Choose the right tool for the job, not the "best" tool everyone recommends