The database is not the problem; table-first thinking is

Many business systems begin with the question “how many tables do we need?” and then follow the path from form, to API, to service, to ORM, to database table. This sequence is efficient and familiar, but it quietly compresses system design into table design.

The database itself is not the problem. It provides persistence, transactions, indexes, constraints, and query ability, and it remains essential for most business systems. The real problem is letting tables become the starting point of thought.

Once a system starts from tables, business behavior is easily compressed into CRUD, complex workflows into a few status fields, and system boundaries into table relationships. Developers may appear to be designing a system while they are mostly wrapping tables with APIs and pages.

Identify facts first, then decide how to persist them

Take an order system as an example. The fact that an order is paid only tells us what the system currently believes. It does not explain who initiated payment, whether the provider retried callbacks, whether the amount was verified, whether inventory was locked, or whether shipment notification succeeded.

If we begin from business facts, the system naturally discovers events such as order created, payment submitted, payment succeeded, inventory locked, and order shipped. They record not only a result at one moment, but why the system reached its current state.

Tables record what the system believes now. Events record why the system believes it. Complex systems need more than final state; they need a chain of facts that can explain how the state was formed.

State should come from rules, not field assignment

Many CRUD systems treat state as a field that can be directly changed. A few enum values look simple, but the field itself cannot explain why it may change or prevent illegal transitions.

An order moving from pending payment to paid should not be just one update statement. A better process checks that the order exists, is still pending, has a matching payment amount, has not already processed the callback, and has not timed out. Only then should the state advance.

At that point, state is no longer just a field. It is the result of rules being applied. The more complex a system becomes, the more state should be treated as a state machine instead of scattered enum values in tables.

Queries are views, not the system itself

Databases also become system centers because they often serve writes, reads, admin screens, operational reports, audit trails, and analytics at the same time. One table keeps accumulating display fields, statistics fields, redundant fields, flags, and compatibility fields.

From a modeling perspective, writes care whether business facts are valid, while reads care how different scenarios should see those facts. User order lists, merchant shipment views, finance reconciliation views, and risk analysis views can all come from the same facts without sharing one structure.

When queries are treated as scenario-specific views, the core table is no longer forced to satisfy every use case at once. The core model stays clearer, and read models can be built around real usage scenarios.

Consistency needs protocols, not only transactions

Database transactions solve local consistency, but real systems often involve payment callbacks, logistics, SMS notifications, asynchronous review, AI inference tasks, cross-service inventory locks, and external synchronization. These actions cannot all be wrapped by one database transaction.

The system then needs business protocols: idempotency so duplicate requests do not duplicate work, retry so failed tasks can be attempted safely, compensation for partial failure, state-machine rules for legal transitions, and reconciliation to find and repair mismatches.

A database transaction ensures that one write does not stop halfway. A business protocol ensures that the system can eventually return to an explainable, recoverable, and traceable state. The more complex the system, the less reliability can depend on transactions alone.

Final Thoughts: databases store data; they should not outsource thinking

Discussing “systems without databases” is not about rejecting databases. Most business systems should still use them because they are mature, stable, economical, and maintainable.

What deserves caution is reducing system design into table design. A better order is to understand business facts, analyze state transitions, define business rules, design collaboration processes, consider query views, and only then decide how data should be persisted.

Databases should carry data, but they should not carry the thinking. The starting point of system design is not tables, but facts, state, rules, and processes. When we can redesign a system under the assumption that the database is temporarily unavailable, we often return to the database with more clarity.