Every year, thousands of Indonesian companies make database decisions they'll regret 2-3 years later. Not because they chose the wrong technology, but because they didn't understand the trade-offs.
This article provides a complete framework for choosing between SQL and NoSQL databases, with real data, Indonesian case studies, and a decision framework you can use immediately.
What is SQL Database??
SQL (Structured Query Language) database, or RDBMS (Relational Database Management System), is a database that stores data in tables with defined relationships.
Key Characteristics
- Rigid schema: Structure must be defined before inserting data
- ACID compliance: Atomicity, Consistency, Isolation, Durability
- Relational: Data connected via foreign keys
- Mature ecosystem: Tools, documentation, and large talent pool
Popular SQL Databases
- PostgreSQL: Open-source, powerful, Indonesia-friendly
- MySQL/MariaDB: Most popular, widely used in Indonesia
- Microsoft SQL Server: Enterprise-grade, common in corporate
- Oracle: High-end, banking & finance in Indonesia
What is NoSQL Database??
NoSQL (Not Only SQL) is a category of databases that don't use the traditional relational model. There are 4 main types of NoSQL databases, each with different use cases.
1. Document Database
Stores data as documents (usually JSON/BSON).
- Examples: MongoDB, Couchbase
- Use case: Content management, product catalog, user profiles
- Advantages: Flexible schema, natural for application modern
2. Key-Value Store
Simplest: one key maps to one value.
- Examples: Redis, DynamoDB
- Use case: Caching, session storage, real-time analytics
- Advantages: Fast, simple
3. Column-Family Store
Data stored in columns, not rows.
- Example: Cassandra, HBase
- Use case: Time-series data, analytics, IoT
- Advantages: Massive scalability, write-heavy workloads
4. Graph Database
Optimized for data with complex relationships.
- Examples: Neo4j, ArangoDB
- Use case: Social networks, recommendation engines, fraud detection
- Advantages: Query complex relationships quickly
Head-to-Head Comparison
When to Use SQL Database
SQL is the default choice for most application. Use SQL when:
1. Need ACID Guarantees
Critical for: Payment, banking, inventory, booking systems.
- Example: E-commerce checkout, transfer bank, booking hotel
- Why: Zero tolerance for data inconsistency
2. Data Highly Relational
When your data is naturally connected with foreign keys.
- Example: ERP systems, CRM, HR management
- Why: SQL join operations very efficient for relational data
3. Complex Queries & Reporting
Need aggregate functions, complex joins, subqueries.
- Example: Business intelligence, reporting dashboards
- Why: SQL query language powerful and expressive
4. Budget Limited & Predictable
Managed SQL (RDS, Cloud SQL) cost predictable.
- Example: Startup with budget total
- Why: No surprise bills, easy capacity planning
When to Use NoSQL Database
NoSQL not "better" from SQL, but "different". Use NoSQL when:
1. Massive Scale (100M+ users)
SQL vertical scaling has limits. NoSQL horizontal scaling limitless.
- Example: Social media, IoT data, global apps
- Why: Can shard across thousands of servers
2. Flexible/Evolving Schema
Schema changes rapidly, or each record has a different structure.
- Examples: User-generated content, product catalogs with many variations
- Why: No need to ALTER TABLE on every change
3. High Write Throughput
Millions of writes per second.
- Example: IoT sensors, log aggregation, real-time analytics
- Why: NoSQL optimized for write-heavy workloads
4. Key-Value Lookup Patterns
Most queries are "get by ID".
- Example: Session storage, caching, user profiles
- Why: Sub-millisecond latency for toy-value lookups
Indonesia-Specific Considerations
1. Data Residency Requirements
PP No. 71/2019: Certain sectors (finance, e-commerce >Rp 100M/year) must store data in Indonesia.
- Impact: Must choose database provider with Indonesia region
- SQL Options: AWS RDS (Jakarta), Google Cloud SQL (Jakarta), Azure SQL (Singapore/Jakarta)
- NoSQL Options: MongoDB Atlas (Jakarta), AWS DynamoDB (Jakarta), Firestore (Jakarta)
2. Cost Comparison (Indonesia Rupiah)
Based on AWS Jakarta region pricing 2026:
- PostgreSQL RDS (db. t3. medium): ~Rp 1.5 million/month
- MongoDB Atlas (M10): ~Rp 1.2 million/month
- DynamoDB: Pay-per-request (~Rp 500k - 3 million/month depending on usage)
3. Developer Talent Pool
In Indonesia, SQL developers are far more common than NoSQL specialists.
- SQL (PostgreSQL/MySQL): Abundant, mid-level ~Rp 12-18 million/month
- NoSQL (MongoDB): Scarce, mid-level ~Rp 15-22 million/month
- NoSQL (Cassandra/DynamoDB): Rare, senior ~Rp 25-35 million/month
Impact: Hiring cost and onboarding time need to be considered.
Database Migration Strategies
SQL → NoSQL Migration
Common scenario: Scale hitting SQL limits.
- Step 1: Identify bottleneck (reads vs writes)
- Step 2: Extract high-volume tables to NoSQL
- Step 3: Dual-write pattern (write to both, gradually shift reads)
- Step 4: Monitor & iterate
Example: Tokopedia product catalog (millions of products) migrated from MySQL to MongoDB for better search performance.
NoSQL → SQL Migration
Less common, usually because: "We over-engineered, actually do not need NoSQL scale."
- Step 1: Schema normalization (NoSQL usually denormalized)
- Step 2: Define foreign keys & constraints
- Step 3: Batch migration with validation
- Step 4: Switch & monitor
Hybrid Approach: Polyglot Persistence
Polyglot persistence is very common inmicroservices architecture, where each service can choose the database that best suits its needs.
Reality: You don't have to choose just one! Modern best practice is using the best tool for each use case.
Contoh Polyglot Persistence
- PostgreSQL: Main transactional data (orders, payments, users)
- Redis: Caching & session storage (sub-ms latency)
- MongoDB: Product catalog (flexible schema)
- Elasticsearch: Search engine (full-text search)
Real Example: Gojek Architecture (simplified)
- SQL (PostgreSQL): Driver data, payment transactions
- NoSQL (Cassandra): Ride history, location tracking
- Redis: Real-time driver location, session cache
- Elasticsearch: Search drivers, restaurants, etc.
Decision Framework: SQL vs NoSQL
Use this checklist to decide:
Use SQL If:
- [ ] Need ACID guarantees (payment, banking, inventory)
- [ ] Data highly relational with many joins
- [ ] Need complex queries & reporting
- [ ] Team familiar with SQL
- [ ] Budget predictable more important than absolute performance
- [ ] Scale: <10 million users
Use NoSQL If:
- [ ] Scale: >100 million users or massive growth expected
- [ ] Schema evolves rapidly
- [ ] Write-heavy workload (millions writes/sec)
- [ ] Queries mostly toy-value lookups
- [ ] Eventual consistency acceptable
- [ ] Budget flexible, optimize for performance over preinctability
Hybrid If:
- [ ] Mix of use cases (transactional + high-volume)
- [ ] Team >10 engineers (can handle complexity)
- [ ] Budget allows multiple database licenses/subscriptions
Case Studies: Real Indonesian Companies
Case 1: E-commerce Startup (SQL)
Company: Mid-size fashion e-commerce, 500K monthly users
- Challenge: Build marketplace with payment, inventory, shipping
- Decision: PostgreSQL on AWS RDS
- Why: Need ACID for payment & inventory, relational data natural
- Result: 3 years running, no scaling issues, cost ~Rp 3 million/month
Case 2: IoT Platform (NoSQL)
Company: Fleet management, 50K+ vehicles sending GPS data
- Challenge: 100M+ location updates per day
- Decision: Cassandra for time-series data, PostgreSQL for transactional
- Why: Write-heavy, time-series, need horizontal scaling
- Result: Handle 100M writes/day, cost ~Rp 15 million/month (Cassandra + RDS)
Case 3: Fintech (Hybrid)
Company: Digital wallet, 5M+ users
- Challenge: Payment (ACID) + high-volume transaction history
- Decision: PostgreSQL (payment), DynamoDB (transaction history), Redis (cache)
- Why: Best of both worlds - ACID where needed, scale where needed
- Result: Handle 1M+ transactions/day, cost ~Rp 25 million/month total
Common Pitfalls & How to Avoid
Pitfall #1: "NoSQL is Faster"
Myth: NoSQL always faster than SQL.
Reality: Depends on use case. SQL with proper indexing can fast for relational queries.
Fix: Benchmark with real workload, don't assume.
Pitfall #2: "NoSQL is Schema-less"
Myth: NoSQL do not need schema.
Reality: Application-level schema still exists. Actually more complex because you must handle it in code.
Fix: Define schema in application layer, use validation libraries.
Pitfall #3: Premature Optimization
Mistake: Using NoSQL for "future scale" when you only have 1000 users.
Reality: YAGNI (You Aren't Gonna Need It). Instagram used PostgreSQL until 10M+ users.
Fix: Start with SQL, optimize later when bottleneck is clear.
Pitfall #4: Ignoring Operational Complexity
Mistake: Use 5 different databases for team 3 engineers.
Reality: Operational burden kills velocity.
Fix: Start simple, add complexity incrementally with clear ROI.
Conclusion
SQL vs NoSQL isn't about "which is better", but "which fits your use case".
Key Takeaways:
- Default to SQL: When in doubt, start with SQL (PostgreSQL recommended)
- NoSQL when clear need: Massive scale, flexible schema, or specific use case
- Hybrid is OK: Use best tool for each job, but do not over-complicate
- Indonesia factors: Consider data residency, cost (Rupiah), talent availability
At Zeppelin Works, we believe database choice is one of the most critical decisions for your application's long-term success. Use the framework in this article to make informed decisions, and don't hesitate to consult experts when needed.
