Is Relevance AI a good fit for a manufacturing company with schema-heavy data

You've hit on the core challenge: translating a dense relational schema into a coherent semantic layer for natural language. From my benchmarking, Relevance AI's approach to handling complex data models is a double-edged sword.

On the data modeling front, its ability to infer and define relationships between your tables is strong for star schemas but can struggle with the deeply normalized, thousands-of-tables environment you describe. You'll likely spend significant time manually curating those "core entities with tons of relationships" to get reliable answers. The system prefers you to define explicit data models and relationships in its semantic layer, which, for a schema of your size, becomes a major configuration project akin to building a second metadata repository.

Regarding your BigQuery integration and cost question, the setup is straightforward for initial connection, but the semantic layer definition is the real work. Cost pitfalls aren't in table volume per se, but in the complexity of the joins your natural language queries trigger. A simple question like "show me machine downtime for parts from supplier X" could, without careful constraint, fan out across your telemetry, parts, orders, and supplier tables, generating massive, expensive joins. You'll need to design your semantic models with performance guards in place, essentially pre-defining the viable join paths. It's less "plug and play" and more "design and govern."

For your stated goal of avoiding SQL training, the platform can get you there, but the upfront time investment from your data team to model and sanitize the query space will be substantial. It shifts the burden from writing SQL to crafting a controlled vocabulary and relationship map.

That's a great point about the cost being tied to query complexity, not just table count. In our limited test, a seemingly simple question about "production yield by line" did pull from a surprising number of tables, which made me nervous about runaway costs at scale.

You mentioned manually curating core entities becomes like a second metadata repo. Does that mean you'd need a dedicated data modeler on the team to maintain it, or is it a one-time setup that stays stable if your underlying schema doesn't change much?

We use it. On the data modeling front, the biggest hurdle wasn't setup, it's ongoing maintenance.

You mention wanting to ask questions "without needing a week of SQL training." That's the goal, but the reality for thousands of tables is that your team *does* need SQL knowledge, or you need a dedicated data modeler. The semantic layer doesn't auto-magically understand your domain logic or which relationships are relevant for "supply chain logistics" vs "machine telemetry."

If your underlying BigQuery schema is stable, you can get it stable. But if your data team is constantly adding new tables or changing joins, expect to constantly tweak the semantic layer. It becomes a parallel modeling effort.

Cost wise, watch your query volume. Complex questions generating 50+ SQL joins will burn through credits fast.

Your point about the parallel modeling effort really hits home. We saw the same thing. The real question becomes: what's the ROI on that ongoing maintenance vs. just having analysts write the SQL?

If your team is already SQL-fluent, you're essentially paying for and maintaining a translation layer. That cost-benefit only works if the number of non-technical users asking questions is very high. Otherwise, you've just shifted the modeling work from one place to another.