Why I Stopped Using MongoDB for Croatian Client Projects

I’ve spent over a decade building backends for Croatian businesses, from boutique hotels on the Dalmatian coast to e-commerce shops in Zagreb. For most of that time, MongoDB was my go-to database for any project that felt modern or needed to move fast. But after three specific projects in the last two years, I made a hard pivot: I stopped recommending MongoDB for any client work in Croatia. Here’s exactly why.

The Local Reality vs. The Marketing Hype

MongoDB sells itself as the database that lets you “just store JSON” and scale infinitely. That sounds perfect for a small startup in Split or a new SaaS launching from Osijek. The problem is that the Croatian market has a very specific set of constraints that the MongoDB marketing team in New York or San Francisco never considers.

The Hosting Infrastructure Gap

Croatian clients rarely have the budget for a multi-region Atlas cluster. They typically run on a single VPS from a local provider like PlusHosting, or a small Hetzner box in Germany. On a single server, MongoDB’s memory-hungry nature becomes a liability. I once had a client in Rijeka running a warehouse-management app on a 4GB VPS. After three months of data, MongoDB was using 3.2GB of RAM just for its working set, leaving nothing for the application itself. The same workload on PostgreSQL used 500MB.

The Backup and Recovery Nightmare

Most Croatian small businesses do not have a dedicated DevOps person. They have me, or someone like me, who comes in once a week. MongoDB’s backup tooling, while powerful, requires a deep understanding of oplogs, replica sets, and point-in-time recovery. When the server in Rijeka had a disk failure, the client’s “backup” was a mongodump from two weeks ago. The restoration process was slow because mongorestore doesn’t play nicely with indexes on a single node. A PostgreSQL pg_dump and restore would have taken a fraction of the time.

The Croatian Tax and Accounting Factor

Here’s the part that no global blog post covers: Croatian businesses deal with very structured financial data. PDV rates, fiskalne blagajne (fiscal cash registers), and strict invoice numbering sequences. MongoDB’s schemaless nature is a liability here. You need to enforce that every invoice has a pdvRate field, that invoiceNumber is unique and sequential, and that certain fields cannot be null. You can enforce this in the application layer, but I’ve seen too many junior developers accidentally insert an invoice without a pdvAmount field, causing the tax report to break silently. Relational databases enforce this at the storage level, which is exactly where you want it for Croatian regulatory compliance.

The Three Projects That Changed My Mind

I don’t make decisions based on theory. I make them based on the pain I feel at 2 AM when a client’s production database is down.

The Booking Engine That Slowed to a Crawl

A client in Dubrovnik needed a booking system for a small apartment complex. The data was “social” in nature: guests, reservations, reviews, and payments. MongoDB seemed perfect because reservations have different structures depending on the season. Six months in, with 15,000 bookings, a simple query like “show me all guests who stayed in July” required a collection scan. The developer had stored the date as a string. Even after fixing the schema, the lack of native JOINs meant that fetching a guest, their booking, and their payment required three separate queries. In PostgreSQL, it’s one query with a single round trip.

The E-Commerce Inventory Fiasco

An online store selling Croatian olive oil and wine started in MongoDB. The owner wanted to be able to add custom fields to products without running migrations. That worked fine for the first 200 products. When they hit 3,000 products with variants (size, harvest year, region), the queries for “show me all available bottles of extra virgin olive oil from Istria under 200 HRK” became a performance disaster. We had to build a complex aggregation pipeline that was slower and harder to debug than a simple SQL query with two JOINs and a WHERE clause.

The Multi-Tenant SaaS That Couldn’t Scale

I built a SaaS for Croatian real estate agents. Each agent has properties, clients, and viewings. MongoDB’s document model made it easy to store a property with its photos and descriptions in one document. But when agents started sharing clients (common in Croatian agencies), the data duplication became absurd. The same client’s contact info was stored in five different documents. Updating a client’s phone number required a multi-document transaction, which MongoDB supports, but it’s slower and more complex than a simple SQL UPDATE with a foreign key.

What I Use Now (And Why It Works Better Here)

I did not switch to a single database. I switched to a strategy that matches the Croatian reality: lower budgets, smaller servers, and a need for strict data integrity.

PostgreSQL for the Core

For 90% of Croatian client projects, PostgreSQL is the better choice. It runs happily on a 2GB VPS. Its JSONB data type gives you the flexibility of MongoDB for truly unstructured data (like CMS page content or user preferences), while still enforcing constraints on critical fields. The backup story is simple: a daily pg_dump to an S3-compatible bucket, restorable in minutes. Croatian developers, even juniors, can write SQL. They struggle with aggregation pipelines.

Redis for the Hot Path

If I need fast reads for a booking calendar or a product listing, I put a Redis cache in front of PostgreSQL. This costs almost nothing and handles the read-heavy workloads that MongoDB was supposed to solve. The difference is that Redis is explicitly a cache, not a source of truth. When it crashes, you rebuild it from the database. When MongoDB crashes on a single node, you lose data.

SQLite for Truly Local Apps

For the micro-businesses—a single bakery in Zadar, a one-person consulting firm—I now use SQLite. It requires zero server setup, zero configuration, and the entire database is a single file you can back up with cp. Croatian clients love this because they can run their app on a cheap laptop or a shared hosting plan. MongoDB never made sense for a one-person operation.

The Real Cost of Flexibility

MongoDB’s biggest selling point is schema flexibility. In my experience, that flexibility is a trap for Croatian projects. When you don’t define a schema, your team doesn’t think about the data model. They throw JSON into a collection and call it done. Six months later, you have a collection with ten different document shapes, and every query has to handle all of them.

A Concrete Anecdote

I took over a project from another developer in Zagreb. The MongoDB collection for “orders” had documents shaped like this:

• Order A: { items: [ { name: "Vino", price: 100 } ], total: 100 }
• Order B: { items: [ { productId: ObjectId("..."), quantity: 2 } ], total: 200 }
• Order C: { items: "two bottles of rakija", total: 150 }

The developer had used the string field “items” for a manual note. The client wanted to generate a sales report by product. It took me two weeks to clean that data. In a relational database, that mess simply cannot happen because the column types are enforced. The Croatian business owner paid for those two weeks. She was not happy.

When I Would Still Use MongoDB in Croatia

I am not a MongoDB hater. I still use it, but only in very specific scenarios that are rare in the Croatian market.

• Event sourcing and logging: If a client needs to store massive amounts of unstructured log data with no need for complex relationships, MongoDB is fine. But I make sure they understand that the logs are disposable.
• Prototyping a complex data model that truly has no fixed schema: For example, a scientific research project where the data structure changes every week. Even then, I migrate to PostgreSQL with JSONB as soon as the schema stabilizes.
• A client with a dedicated DevOps team and a budget for a three-node Atlas cluster. I have exactly zero clients in Croatia who fit this description.

The Practical Takeaway

If you are a developer in Croatia building for a Croatian client, ask yourself one question before you choose MongoDB: “Will my client’s accountant or tax advisor ever need to run a report on this data?” If the answer is yes—and it almost always is—use a relational database. Start with SQLite for small projects, PostgreSQL for anything that will grow, and keep MongoDB in your toolbox for the rare case where the data truly has no shape. Your clients will thank you when the backup works, the reports are accurate, and the server doesn’t run out of memory on the first of the month.

The next time you’re in a coffee shop in Zagreb or on a video call with a client in Pula, remember: the best database is the one that stays out of your way and lets you go home on time. For the Croatian market, that database is almost never MongoDB.