Direct Postgres over the BaaS SDK

The database boundary does not disappear because a backend-as-a-service offers an SDK. Sometimes the clearer abstraction is the database itself.

Direct Postgres access carries the same pooling and schema knowledge into a second runtime. The decision is not an argument against a BaaS; it is an argument for choosing the boundary that keeps the system understandable.

Keep the schema visible

An SDK can be a productive interface, especially when it removes repetitive plumbing. But when a workflow depends on connection behavior, transaction boundaries, or query shape, the underlying Postgres model still matters.

SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name = 'extraction_results'
ORDER BY ordinal_position;

That query is unglamorous and useful. It makes the contract inspectable instead of hiding it behind a second vocabulary.

A coherence argument

Using direct Postgres in a second runtime extends the same knowledge rather than introducing another access model to maintain. The result is not “always use SQL.” It is a deliberate choice to keep pooling, schema, and query behavior in one mental model when those details are load-bearing.