A

What a database actually is

Your application needs to remember things. User accounts. Orders. Messages. Product inventory. A database is the system that stores and retrieves that information reliably — even when the server restarts, even when two users write data at the same time, even when something crashes halfway through an operation.

That last part is more important than it sounds. It's easy to store data. Storing it correctly under failure conditions is the hard part, and it's where database engines earn their reputation.

Every time a user signs up, places an order, or sends a message, your application writes to the database. Every time a user loads a page, your application reads from it. At low traffic, the database is invisible. At high traffic, it becomes the most common bottleneck in the system — which is why understanding the basics now saves expensive conversations later.

SQL databases: structured, reliable, decades of trust

SQL stands for Structured Query Language. It's the language you use to talk to a relational database. The "relational" part means your data is organised into tables with rows and columns — like a spreadsheet, but with strict rules about what can go where and how tables relate to each other.

is the most widely used open-source SQL database. MySQL is another common one. If your team chose either of these, they chose a system that has been handling production workloads for decades, has extensive tooling, and behaves predictably under most conditions.

SQL databases enforce structure. Before you can store data, you define a schema — what columns exist, what type of data each holds, what's required. This feels rigid early on, but it's a feature, not a limitation. That rigidity catches data quality problems at the point of entry rather than three years later when you're trying to run a financial report and find that half your records have a null where an amount should be.

They also handle transactions. If your payment system deducts money from one account and credits another, a SQL database guarantees that either both operations succeed or neither does. There's no world where the debit happens and the credit doesn't. For anything involving money or inventory, this property — called ACID compliance — is not negotiable.

NoSQL databases: flexible, fast, and frequently misunderstood

NoSQL doesn't mean "no SQL" exactly — it means "not only SQL." It's an umbrella term for databases that don't use the relational table model.

They come in several flavours. Document databases (MongoDB is the most common) store data as JSON-like objects. There's no fixed schema — each record can have different fields. Graph databases store data as nodes and edges, useful for social networks or recommendation engines. Column-family databases (Cassandra) are optimised for write-heavy workloads at massive scale. Key-value stores like store simple pairs of identifiers and values, often in memory, and are commonly used as caches rather than primary databases.

The appeal of NoSQL, especially for early-stage teams, is flexibility. You don't need to define your schema upfront. You can change the shape of your data without database migrations. For a product that's still figuring out what it is, that flexibility feels valuable.

The tradeoff: you give up some of the guarantees that relational databases provide by default. Consistency across multiple operations requires more careful application-level code. Queries that are trivial in SQL can become complex or slow. And the lack of enforced schema means data quality problems tend to accumulate quietly until they become a significant problem to clean up.

The part most founders get wrong

NoSQL is not the modern choice. Postgres is not the legacy choice. This framing — which shows up constantly in engineering debates — is wrong, and it leads to bad decisions.

MongoDB became popular in the early 2010s partly because it was new and partly because it was genuinely useful for certain workloads. A generation of developers adopted it as the default. Then, over time, a lot of those teams found themselves wishing they had stricter data guarantees, or struggling to run queries that a SQL database would have handled cleanly.

The honest answer is that for most startups, a SQL database is the right default. Your data has more structure than you think it does. Your queries will become more complex over time, not less. And the operational tooling — backups, migrations, monitoring, cloud hosting options — is more mature for SQL databases than for most NoSQL alternatives.

NoSQL is the right call for specific problems: you're storing genuinely schema-less data, you need horizontal write scale that SQL can't match, or you have a graph or time-series use case that maps naturally to a non-relational model. Those are real scenarios. They're just not most startups.

If your team chose MongoDB because "it's more flexible," that's worth a conversation. Flexibility at the data layer often means rigidity moved somewhere else — into your application code, where it's harder to see and harder to enforce.

How this plays out at scale

Tokopedia, in its early architecture, used a fairly conventional relational database setup. As transaction volume grew — millions of product listings, hundreds of thousands of concurrent users — the database became a bottleneck. Their response wasn't to switch database paradigms wholesale. It was to add caching layers, shard the database horizontally, and move specific high-volume workloads to purpose-built stores where the access patterns made that worthwhile.

That pattern — start relational, optimise precisely where the pain is — shows up in most scaled Indonesian tech companies. The reason is practical: you understand your data better after running a product for two years than you do on day one. A SQL database lets you start with strong guarantees and make targeted optimisations later. Starting with NoSQL and trying to add guarantees later is considerably harder.

For a closer look at what happens when your database becomes the bottleneck, see [→ Read: What is database sharding — and when does your startup actually need it]. And for the broader picture of how databases fit into your overall system design, [→ Read: What Is Software Architecture?] covers the full stack.

FAQ

Q: Should we use Postgres or MongoDB?

A: For most startups, Postgres. It handles relational and document-style data well (it has a native JSON column type), enforces data integrity, and has excellent managed hosting options. Choose MongoDB only if you have a specific, well-understood reason — not because the team is more familiar with it or because it seems simpler to start.

Q: What does "schema" mean and why does it matter?

A: A schema is the definition of your data structure — what tables exist, what columns they have, what types of data are allowed. In SQL databases, the schema is enforced by the database itself. In NoSQL, it typically isn't. A well-designed schema prevents bad data from entering your system in the first place, which becomes extremely valuable once you're running reports or doing anything analytical.

Q: Can we switch databases later if we choose wrong?

A: Technically yes. Practically, it's one of the most painful engineering projects a team can undertake. Your queries, your ORM configuration, your migration history, your backup processes — all of it is coupled to the database. Switching is possible; it's just expensive enough that most teams don't do it until the pain of staying is worse. This is why the initial choice matters.

Q: What is a migration?

A: A migration is a tracked change to your database schema — adding a column, renaming a table, changing a data type. Well-run engineering teams version their migrations the same way they version code, so the database schema and the application code stay in sync. If your team isn't doing this, it's a meaningful gap.

Q: When does a startup need more than one database?

A: Usually not until you have a specific performance or scale problem that the primary database can't handle. Some teams add Redis for caching early, which makes sense. Running separate Postgres instances for separate services is worth considering once you move toward a microservices model. Adding a second database "just in case" before you have a measured reason adds operational complexity with no current benefit.

The database decision doesn't feel consequential when you're making it at 5,000 users. At 500,000, it's the foundation everything else is built on. Most of the time, the right call is also the boring one — pick Postgres, define your schema carefully, and save the exotic data stores for problems you can actually measure.