The recent article “Your Database Table is an awful API” claims that exposing database tables (or database-derived structures) as integration boundaries between systems is a bad idea. It warns about tight coupling, hidden dependencies, scalability bottlenecks, and unclear semantics. (innoq.com)

That article speaks to a particular anti-pattern, sharing raw tables or entire schemas directly between applications that evolve independently. But it misses an important point: a well-designed database view (or materialized view) is not the same thing as exposing internal tables without control. And in many contexts, views are a strong contender as data-driven APIs that are simple, evolvable, and efficient.

When is a View “Just a Table”?

A database view is a virtual table defined by a SELECT query. Clients can query it just like a real table, but the database computes the result on demand. There are also materialized views where the query result is precomputed and stored, often refreshed asynchronously, which is useful when performance matters. (CData Software)

Many people treat views as if they were just another table because they expose a stable, queryable interface. But conceptually, they are API contracts:

  • They define exactly what data is relevant, hiding internal table joins or normalization.
  • They encapsulate business logic and derived fields in a single location.
  • They let the database engine optimize performance — especially materialized views.

A view can shape the data format, semantics, and constraints that a consumer sees. In that sense, there is no meaningful difference between a view and a GET endpoint in a REST API. Both serve read-only structured data that other systems consume.

Views as Clear, Stable Contracts

One key argument in the INNOQ article is that exposing tables causes tight coupling because the schema becomes the contract. But this is really an argument against exposing an internal schema verbatim, not against logical views.

Views let you evolve your internal schema without breaking consumers:

  • You can add, remove, or rename underlying fields while keeping the view stable.
  • You can include derived or aggregated data without making clients compute it themselves.
  • You can restrict what consumers see, which is a crucial part of information hiding.

In practice, this means the view is the API contract. Clients don’t depend on internal table structure (even if they are querying the database directly), they depend on the view’s definition — exactly like they depend on an API documentation or OpenAPI spec.

Performance Isn’t a Weak Spot

A common misconception is that “SQL access is slow” versus “REST API is fast”. In reality:

  • Database engines are highly optimized for set-based queries, caching, and parallel execution.
  • Materialized views give you precomputed results that can be as fast or faster than API queries pushed through an application server.
  • Avoiding a middle tier for simple data access removes unnecessary serialization/deserialization and HTTP hops.

Yes, REST APIs can add HTTP caching, auth layers, and tooling benefits. But for machine-to-machine communication in SCS patterns — where systems trust each other and security is handled at the network level — database views can be simpler and more efficient.

Security and Access Control

Database systems have mature mechanisms to control access:

  • Row-level and column-level security restrict exactly what a query can see.
  • Views expose only the necessary columns.
  • Materialized views can precompute data that would otherwise require complex authorization logic in application code.

So security is not inherently worse with views — it’s just a different layer to configure.

Views as a Replication Mechanism in Self-Contained Systems

In a Self-Contained Systems architecture, each system owns its data. That ownership is not optional. It is fundamental. But ownership does not mean isolation. Systems still need data from other systems. The real question is how that data is exposed and consumed.

A database view can serve as a deliberate replication boundary.

Instead of allowing direct access to internal tables, a system can expose a dedicated integration view that represents exactly the data other systems are allowed to consume. This view becomes the replication source. Downstream systems can:

  • Pull data periodically.
  • Replicate it into their own database.
  • Transform it into their own domain model.
  • Build their own indexes optimized for their workload.

If performance matters, a materialized view can precompute and snapshot the data. This reduces load on the core domain while still offering a consistent export contract.

This approach has several advantages in SCS:

  1. Clear ownership
    The producing system owns its internal schema. Consumers never see it. They only see the exported projection defined by the view.
  2. Controlled coupling
    The view defines the contract. If internal tables change, the view can remain stable. Consumers depend on the projection, not on implementation details.
  3. Explicit replication
    Instead of hiding replication inside application code or event pipelines, the database expresses the export logic declaratively. The replication boundary is visible and versionable.
  4. Consumer autonomy
    Once replicated, the consuming system is independent. It can scale, reshape, cache, and query the data according to its own needs without affecting the source system.

In this sense, a view is not “a shared database”. It is a published read model. Conceptually, it is similar to a REST GET endpoint that returns a structured representation. The difference is only the transport protocol. The contract principle is the same.

For many SCS scenarios within a trusted network, using views or materialized views as replication sources is simpler, more transparent, and often more efficient than building and maintaining an additional HTTP API layer that does nothing more than execute a SELECT and serialize the result.

Used deliberately, views are not an architectural shortcut. They are a precise, declarative integration mechanism.

Conclusion

The critique in “Your Database Table is an awful API” applies to naive shared schemas, not to designed, reviewed, and controlled database views used as integration contracts. When done right:

  • Views act as stable contracts between systems.
  • Materialized views support high performance without needless layers.
  • Clients can evolve independently as long as the view contract stays stable.

In many architectures database views are not just good enough. They are an elegant, efficient, and robust data-driven API for integrating systems.