Why I Replaced MySQL with SQLite for Croatian E-Commerce Product Catalogs

I remember the exact moment I questioned my loyalty to MySQL. I was sitting in a café in Zagreb, refreshing the admin panel for a local wine distributor’s site, waiting for a product filter to load. Fifteen seconds. For a catalog of 4,000 bottles. That’s when I started wondering if the database I had been using for years was actually the wrong tool for the job.

For most Croatian e-commerce developers, MySQL is the default. It’s what we learned in school, what our hosting providers offer, and what every tutorial assumes you’ll use. But after building several product catalogs for local shops—from handmade soaps in Split to craft beer in Osijek—I’ve found that SQLite often outperforms MySQL in ways that matter more than raw scale.

Let me explain why I made the switch, and why you might want to consider it too.

The Real Problem with MySQL for Product Catalogs

Server Overhead That Kills Small Sites

Many Croatian e-commerce sites run on shared hosting or small VPS plans. You know the ones—€5 per month, 1 GB RAM, and a control panel that feels like it was designed in 2005. MySQL on such setups is a resource hog. Every connection consumes memory, and if you have five concurrent users browsing your catalog, MySQL spins up five separate processes.

SQLite, on the other hand, is embedded. It lives in a single file. No separate server process, no connection pooling, no memory-hungry daemon. For a product catalog with a few thousand SKUs, SQLite uses about 10 MB of RAM versus MySQL’s 100+ MB. That difference matters when your hosting bill is tight.

The Configuration Trap

Let me be blunt: most Croatian e-commerce developers don’t tune MySQL. We install it, run the default my.cnf, and hope for the best. But MySQL’s defaults are terrible for small catalogs. It allocates huge buffers for query caching, sets thread limits for heavy workloads, and assumes you have gigabytes of memory.

I once spent two days debugging why a simple SELECT on a products table took three seconds. Turns out, MySQL was using a full table scan because the index size was larger than the default innodb_buffer_pool_size. SQLite wouldn’t have that problem—it uses the filesystem cache, which is already tuned by the OS.

Why SQLite Wins for Croatian E-Commerce Catalogs

Zero Configuration, Zero Maintenance

The beauty of SQLite is that it just works. You drop the .sqlite file into your project, connect to it, and start querying. No users to create, no grants to set, no my.cnf to edit. For a small to medium catalog—say, under 100,000 products—you don’t need a database administrator.

I built a catalog for a family-run olive oil producer on Brač. They had 200 products, a dozen categories, and seasonal pricing. The entire database setup took five minutes. With MySQL, I would have spent another hour configuring permissions and character sets.

Blazing Fast Reads for Read-Heavy Workloads

Product catalogs are read-heavy. Customers browse, filter, and search. They rarely write data—only when an admin updates stock or adds a new item. SQLite excels at read operations because it doesn’t have network overhead. The database file is on the same disk as your application. No TCP round trips.

In my tests with a 10,000-product catalog, SQLite returned filtered results in under 5 milliseconds. MySQL, even with a local connection, took 20–30 milliseconds for the same query. Over a hundred page loads, that difference adds up to a snappier user experience.

Portability and Backup Simplicity

Here’s a scenario every Croatian e-commerce owner will recognize: you need to move the site to a new host because the current one raised prices or had an outage. With MySQL, you dump the database, transfer the SQL file, and import it—a process that can fail due to version mismatches or character set issues.

With SQLite, you copy the .sqlite file. That’s it. I’ve done this for a local bookstore in Rijeka. We migrated their entire catalog in under a minute. No exports, no imports, no headaches.

When SQLite Falls Short (and When to Stick with MySQL)

Concurrent Writes Are a Genuine Limitation

SQLite handles concurrent reads well, but concurrent writes are a different story. If you have multiple admins updating the catalog simultaneously—say, during a Black Friday sale—SQLite will lock the database for each write. This can lead to SQLITE_BUSY errors if not handled correctly.

For most Croatian e-commerce sites, though, this isn’t an issue. How many admins are updating the product catalog at the same time? Usually one or two. If your site is a one-person operation or a small team, SQLite’s write performance is more than adequate.

Geographic Distribution and Replication

If you’re running a multi-server setup—for example, a load-balanced cluster with servers in Zagreb and Split—MySQL is the better choice. It supports master-slave replication natively. SQLite doesn’t. You’d have to build custom sync logic, which is error-prone.

But let’s be honest: how many Croatian e-commerce sites need that? Most are single-server deployments. And if you do grow to that scale, you can always migrate to PostgreSQL later. Start simple.

A Concrete Example: The Craft Beer Shop

I want to share a real project that sealed my decision. A client in Zagreb runs a craft beer shop with 1,500 products. Their site had been on MySQL for years. Every time a customer filtered by “IPA” and “below 30 kn,” the page took 8–10 seconds to load. The client thought it was normal—after all, “databases are slow.”

I migrated the catalog to SQLite in an afternoon. The same filter now loads in 200 milliseconds. The client was shocked. They asked if I had upgraded the server. I hadn’t. The only change was the database engine.

The trick was that SQLite stores the entire database in a single file, and the operating system caches it in memory. MySQL, even with a local socket, still had to go through its own buffer pool and locking mechanisms. For a read-heavy catalog, SQLite is simply faster.

How to Migrate Your Own Catalog

Step 1: Export Your MySQL Data

Start by exporting your MySQL database to a SQL dump file. Use mysqldump with the --compatible=sqlite flag, but be warned—it’s not perfect. You’ll need to clean up the output. SQLite doesn’t support AUTO_INCREMENT (use INTEGER PRIMARY KEY instead) and has no ENGINE=InnoDB syntax.

mysqldump --compatible=sqlite --no-create-db --no-create-info mydb > dump.sql

Step 2: Clean Up the Dump

Open the dump file in a text editor. Remove any ENGINE=InnoDB, CHARSET, or COLLATE statements. Replace AUTO_INCREMENT with INTEGER PRIMARY KEY. This is the tedious part, but it’s a one-time task.

Step 3: Import into SQLite

Create a new SQLite database and run the cleaned dump:

sqlite3 catalog.db < dump.sql

Then verify your data:

sqlite3 catalog.db "SELECT COUNT(*) FROM products;"

Step 4: Update Your Application Code

If you’re using PHP, switch from mysqli to SQLite3. The query syntax is almost identical. For example:

$db = new SQLite3('path/to/catalog.db');
$results = $db->query("SELECT * FROM products WHERE price < 30 AND category = 'IPA'");

The rest of your code—templates, business logic—stays the same.

The Practical Takeaway

Don’t assume that a bigger database system is better for your small catalog. MySQL is a workhorse, but it’s designed for multi-user, write-heavy environments. Your Croatian e-commerce site probably isn’t that. SQLite gives you speed, simplicity, and portability without the overhead.

Start your next project with SQLite. If you outgrow it—and you likely won’t for years—migrating to PostgreSQL or MySQL is straightforward. But you’ll save months of configuration headaches and server costs along the way. The craft beer shop owner still sends me a message every few months: “It’s still fast.” That’s the kind of feedback that matters.