I like seeing table and column names in the editor while writing a query. If I mistype a column, I'd rather find out before running the app. That's the first thing I want from a TypeScript query tool.
Correct types don't guarantee the query will work against the database, though. If the schema changed and the migration hasn't been applied, compiling the code doesn't solve much. Type checking and the database's actual state need separate attention.
Being able to inspect a query
When a query gets slow, I want to see the SQL it runs. Row counts, joins and indexes still matter. If a tool makes that hard to inspect, I lose some of the convenience it gave me while writing the query.
So I don't choose a tool only by how little code it takes. Being able to see the query, review migrations and write SQL directly when needed matters to me.
Where the service runs also affects the connection. I need to check the driver and connection method against that project's runtime. A single comparison table isn't enough to decide for every database and deployment environment.
What TypeScript checks
Suppose I describe a query result like this:
type PlaceRow = {
id: string;
name: string;
};
function placeLabel(place: PlaceRow) {
return place.name.toUpperCase();
}
If I write place.title, TypeScript can tell me the field doesn't exist. Marking an external object as PlaceRow doesn't check its fields, though. It tells the compiler what to assume. To trust the actual value, I need runtime validation or a reliable data boundary. The TypeScript documentation explains that distinction.
There's a similar boundary at the database. If my code expects a name column but the connected environment doesn't have it, the query fails. A migration changes the database schema through SQL; changing a TypeScript type doesn't apply that change.
Why I want to see the SQL
For example, I want the ten most recently created places:
SELECT id, name
FROM places
ORDER BY created_at DESC
LIMIT 10;
Even if I write it through an ORM, a query like this reaches the database. If the result is wrong, I'd check the filters, ordering and which environment I'm connected to. If it's slow, I need its execution plan. Short query code alone doesn't tell me how it performs.
Type safety sits alongside those checks. Catching mistakes in the editor is useful; the connected schema and actual SQL still need attention.