> Accessing data is a challenge to team members who aren’t data analysts or engineers
To me it seems that the product is more or less built around this notion. Which is weird. In my experience, unless there are strict reasons why one cannot have access to raw data, access is usually one approval away.
> we pass the relational schema on top so we can easily know the relationships between your tables.
Take a look at any production database that has survived a decade of continuous development. It's batshit crazy. There will be 3 different tokens in field names denoting the very same thing. Some relationships will be defined in the schema, some in procedures, some in application code. Values will be scaled/encoded differently in tables from different generations. Quite possibly there will be "read only" tables of historical data following entirely different schema. What does null value field mean in EAV table? It may mean absence of value (how is it different from absence of the attribute?), explicit inapplicability of the attribute or `any` value.
Not including any of these quirks returns wrong data, but it does not tell you and it is not always obvious that the data is incorrect. Validating complex queries is not that easy. For most business questions wrong data is strictly worse than no data.
IIUC, Outerbase connects directly to the database, takes a dataset that does not easily yield to simple join-and-filter composition, writes a query without incorporating all the data quirks and spits it out to a rather rudimentary sql explorer. That is one of the major reasons why read only access to raw data is restricted in the first place. The value proposition here is murky to say the least - it does not take much training to teach someone to write rudimentary selects.
But if companies take the resources to make data easily analyzable and build a data warehouse, they want to use powerful reporting tool like PowerBI or Tableau. Outerbase seems to fall very short here.
So, where in the team does Outerbase fit? Support and business people need data pre-validated to be correct, DBAs hand-optimize queries. Devs either work with some form of ORM/DAO or write composable queries that need a very specific structure anyway.