SQLite for Small Business: The Myth That You Need a Real Database Server - Autom84You

The Myth: SQLite for Small Business Is a Toy That Can't Handle Real Work

Here's what most developers and agency salespeople will tell you: SQLite is for prototypes, mobile apps, and hobby projects. If you're running a real business - taking orders, managing inventory, tracking customers - you need a real database. MySQL at minimum. Postgres if you're serious. Probably hosted on AWS RDS or PlanetScale, running $25-$100 a month before you've stored a single row.

The implication is clear: SQLite for small business use is reckless. Unprofessional. Something you'll outgrow in a week.

That's the myth. Let me show you why it's wrong for probably 80% of the small businesses I've built systems for over the past two decades.

Why People Believe This (And Why It's Not Stupid)

The skepticism isn't baseless. It comes from three real concerns:

Concern 1: Concurrency. SQLite uses file-level locking. If two users write at the exact same millisecond, one waits. In a world where everything is described as needing to "scale," this sounds fatal.

Concern 2: No network access. SQLite runs in-process. You can't have a separate app server and database server on different machines. For large teams and microservices, that's a genuine limitation.

Concern 3: Industry inertia. Every tutorial, every bootcamp, every SaaS template assumes MySQL or Postgres. When you've only ever seen one path, alternatives look risky.

These concerns are valid - for Uber, for Stripe, for companies processing thousands of concurrent writes per second. For a dog grooming shop's appointment system? A wedding photographer's client portal? A taco truck's inventory tracker? Those concerns are solving problems that don't exist.

The Reality: SQLite for Small Business Handles More Than You Think

A KDnuggets benchmark recently tested SQLite against DuckDB and Pandas on one million rows - SQLite held its own for standard query patterns that any small business would run. We're talking inventory lookups, sales reports, customer searches.

Here's the threshold I use: if your application serves fewer than 100 concurrent users performing write operations at the same time, SQLite is not just adequate - it's often the better choice. Why?

• Zero configuration. No database server to install, patch, restart, or monitor. The database is a single file.
• Zero monthly cost. No RDS bills. No managed database subscription. The file sits on your server's disk.
• Instant backups. Copy one file. Done. No pg_dump scripts, no cron jobs piping to S3.
• Fewer failure points. No network timeouts between app and database. No connection pool exhaustion at 3 AM. No credential rotation breaking your app.

PHP - which I still choose for most small business builds in 2026 - has had excellent SQLite support baked in since version 5.3. The PDO interface means switching between SQLite and MySQL later requires changing exactly one connection string. You're not locked in.

Three Businesses Running on SQLite Right Now

1. A Sunnyvale HVAC company's service tracker. I built them a custom job management system last year. Technicians log visits, upload photos, track parts used. Fifteen field techs, one office manager, maybe 200 new records per day. Their database file is 47 MB after 14 months. The server costs $5/month on a basic VPS. Their previous solution was a $180/month SaaS tool that did less.

2. A Sacramento bakery's order system. Online ordering, production scheduling, ingredient inventory. Peak load is Saturday mornings - maybe 30 orders in an hour. SQLite handles that without thinking about it. Total hosting cost: $12/month. The bakery owner manages everything through a custom admin panel that loads in under 200ms because there's no network hop to a database server.

3. A solo real estate agent's CRM. Contact management, showing schedules, automated follow-up emails. Under 500 active contacts. The entire system - PHP backend, SQLite database, and static frontend - runs on a $4/month server. The agent's previous CRM cost $79/month and required a browser extension that broke every Chrome update.

None of these businesses will ever need to migrate away from SQLite. Their data will never exceed what a single server can handle. They're not building the next Facebook - they're running a business, and their tech should be as boring and reliable as their electricity.

When SQLite Isn't the Right Call

I'm not arguing SQLite works everywhere. Skip it when:

• Multiple application servers need to write to the same database simultaneously (use Postgres)
• You're building a SaaS product that might actually hit thousands of concurrent users (use Postgres)
• You need real-time replication across data centers (use a managed service)
• Your team has 10+ developers who all need direct database access for debugging (use something with network access)

But notice the pattern - these are all scenarios with significant scale or team complexity. A five-person dental practice booking system? A florist's delivery route planner? A personal trainer's client tracker? SQLite handles all of these without breaking a sweat, and you save $50-$200/month in database hosting fees that add up to real money over years.

How to Use SQLite for Small Business Projects the Right Way

If you're a developer building for small businesses (or a business owner evaluating proposals), here's what good SQLite implementation looks like:

Enable WAL mode. One line of code: PRAGMA journal_mode=WAL; - this allows concurrent reads while a write is happening. Night and day difference for web apps.

Use parameterized queries. Same as any database - never concatenate user input into SQL strings.

Back up the file daily. A simple cron job that copies the .db file to a second location. Five minutes to set up, runs forever.

Set a busy timeout. PRAGMA busy_timeout=5000; - if a write is in progress, wait up to 5 seconds instead of failing immediately. For small business traffic, conflicts basically never happen, but the safety net costs nothing.

Keep it on an SSD. Modern VPS providers give you SSD storage by default. SQLite on spinning disk is noticeably slower - on SSD, it's effectively instant for small-business workloads.

I've shipped dozens of these systems through my practice, and the maintenance burden is genuinely close to zero. No database patches, no version upgrades to schedule, no connection strings to rotate. The app just works, month after month.

The Real Cost Comparison

Let's put real numbers on a typical small business web app:

The popular path: Laravel or Node app + managed MySQL on DigitalOcean ($15/mo) or AWS RDS ($25-$50/mo). Total hosting: $25-$60/month. Annual: $300-$720.

The SQLite path: PHP or Python app + SQLite file on a $5-$12/month VPS. Total hosting: $5-$12/month. Annual: $60-$144.

Over five years, the difference is $1,200-$2,800. For a solo business owner, that's not trivial - it's a new laptop, or six months of marketing budget, or just less stress about recurring costs eating into margins.

And the SQLite version is simpler to maintain, simpler to back up, and has fewer moving parts that can break at 2 AM on a holiday weekend.

The Bottom Line

The myth that SQLite for small business is inadequate persists because the people recommending database solutions are usually solving for much larger problems than most small businesses actually have. A system that handles ten million concurrent users is impressive engineering - and completely irrelevant to a plumber's appointment scheduler.

Match your tools to your actual problem. For most local businesses with under 50 employees and under 100 daily active users, SQLite isn't a compromise. It's the technically correct choice that also happens to be the cheapest one.

If you've got a system running on a $50/month managed database and you're not sure whether you actually need it - shoot me a message at nerd@a84y.com. I'll look at your setup and tell you honestly whether you could simplify. Sometimes the answer is yes, and sometimes the managed database is genuinely the right call. Either way, you'll know - and knowing beats guessing. More about what I build at autom84you.com.