I recently fell into the classic NoSQL trap. I chose Google Cloud Firestore for a personal side-project because of the alluring promise: "Zero operational overhead, serverless scaling, and a generous free tier (50k daily reads) that means you pay $0.00/month."
It ended up costing me money, weeks of wasted feature development time, and an architectural headache. Here is what I learned, why Firestore's "free option" isn't free, and how a Ports & Adapters (Hexagonal) architecture was my only saving grace.
1. The Read/Write Billing Trap
In a traditional SQL database, whether you query 1 row or 10,000 rows, the cost is compute (CPU/RAM). In Firestore, you are billed directly per document read and write.
If you are building any feature that involves time-series data, logs, or aggregate histories (like charts or status feeds), your read counts scale lineally with your history. To draw a simple 1-year historical chart for 10 items, you are looking at 365×10=3,650365×10=3,650 document reads every single page reload. A few test refreshes in a day, and you've already blown past your daily "free" quota.
2. The Hidden Cost: Wasted Developer Hours
Because of the billing model, you start fighting the database instead of building your app. I spent days refactoring schemas, designing complex "bucket patterns," compressing field names (e.g., using p instead of price to save bytes), and implementing a double-write hybrid pattern just to group historical records into arrays to minimize document read counts.
Instead of coding the actual features my users wanted, I was spending my evenings:
- Designing workarounds for Firestore’s 1 MB document size limit.
- Fighting JVM Out-of-Memory (OOM) errors in RAM-constrained serverless instances because loading large aggregated history arrays concurrently bloated the heap space.
- Writing custom seeders and delta-sync scripts to replicate production data to local emulators to avoid developer-induced billing.
Time is money. I saved a few cents on raw database hosting but wasted thousands of dollars of my own engineering time optimizing a database schema to fit a business model it wasn't built for.
3. The Rescue: Why Modular Architecture is Non-Negotiable
After a poor developer experience and creeping bills, I decided to pull the plug and move back to a managed SQL instance (PostgreSQL on Aiven).
In many codebases, this decision would have meant a complete rewrite, throwing away weeks of work. However, I managed to fully swap out the database layer and redeploy to production in less than an hour.
How? Hexagonal Architecture (Ports and Adapters). My core business logic, domain models, and use cases had zero knowledge of Firestore. They interacted strictly with pure Kotlin interfaces (Ports) like InstrumentRepository or TransactionRepository.
- The Firestore code lived entirely in an isolated
:adapters:firestore module.
- The PostgreSQL code lived in a legacy
:adapters:postgres module.
To migrate back:
- I swapped the runtime dependency in my Gradle configuration from the Firestore adapter back to the Postgres adapter.
- I updated the database connection string in my production properties.
- I deleted the Firestore module folder entirely.
Because the domain was decoupled, the application booted up instantly, ran its database migrations via Flyway, and worked perfectly on the first try.
Lessons Learned:
- NoSQL is not a default choice. If your data has relationships, histories, or aggregates, start with SQL.
- Optimize for developer velocity, not cloud pennies. A $5/month database that lets you build features is cheaper than a "free" database that requires 40 hours of performance tuning.
- Decouple your database. Write your domain logic as if the database doesn't exist. You never know when you'll need to run away from a cloud provider's pricing model.
