Architecture and Tech Stack Fit

Architecture fit is the evaluation criterion that eliminates vendors fastest — and the one teams most often check last. A platform that scores well on features, pricing, and demo polish can still be the wrong choice if it can't run in your deployment environment or connect to your data the way your architecture requires.

This chapter covers the architectural questions to answer before you invest time in a trial. Getting these wrong wastes evaluation cycles. Getting them right narrows your shortlist to platforms that can actually work.

Deployment Model — Self-Hosted vs. Cloud-Only

The first question: where does the platform run?

Cloud-only platforms run on the vendor's infrastructure. You connect to them via API; your data goes to their servers for query processing and rendering. This is the default for SaaS-native analytics vendors — it's operationally simpler for them to support.

Self-hosted platforms run on your infrastructure — your servers, your cloud tenant, your customer's on-premises environment. Your data never leaves your control. The vendor ships software; you run it.

For ISVs, the deployment model question isn't just about preference — it's often a customer requirement. Enterprise customers frequently have data residency requirements: customer data must stay in a specific geographic region, or on-premises, or in the customer's own cloud account. A cloud-only analytics platform can't serve those customers. If even a fraction of your target market has on-premises or data sovereignty requirements, cloud-only is an architectural dead end.

Self-hosted also means you control the upgrade cadence, the security patch schedule, and the infrastructure performance. You're not sharing compute with other vendors' customers. You're not dependent on the vendor's cloud availability for your product's analytics to work.

Database Compatibility

The analytics platform connects to your database. Confirm compatibility before anything else — it sounds obvious, but "we support most databases" is not the same as "we support your database."

Questions to ask directly:

Which databases does the platform connect to natively? SQL Server, PostgreSQL, MySQL, Oracle, MongoDB, Snowflake, BigQuery — the list varies significantly by vendor. Some platforms are built around a specific database backend (which affects performance and feature availability). Others support a broad range via JDBC/ODBC. Know which yours is.

Does the platform require a specific database for its own internal operations? Some analytics platforms use a database for their own metadata, report storage, and user management — separate from your application database. If that internal database must be SQL Server and you're on PostgreSQL, that's an operational dependency to plan for. Yurbi uses Microsoft SQL Server as its internal backend — this matters if SQL Server isn't already in your environment.

How does it connect to multiple databases? If each of your customers has their own database instance — a common architecture for ISVs with enterprise customers — the platform needs to support dynamic connection routing. See Chapter 4 for the security implications; the architecture question here is whether connection strings can be configured per-tenant and resolved at query time, or must be set statically at platform configuration time.

Your Application's Tech Stack

The analytics platform needs to integrate with your application — not just your database. The integration points that matter:

SSO and authentication. How does the platform accept your authenticated users? Most ISV integrations use a server-side token exchange: your application calls the analytics API to generate a session token for the authenticated user, then passes it to the client-side embed. Confirm the platform has documented API support for this pattern — not a bespoke professional services engagement.

Embedding mechanism. iframe embedding or JavaScript SDK? iframes are supported by all platforms and fastest to implement. JavaScript SDKs give tighter UI control but require more integration work. Chapter 5 covers this in more detail. The tech stack question here is whether your frontend framework has any documented integration examples for the platform you're evaluating — which saves time when your developer starts the trial.

API completeness. Beyond embedding, does the platform have an API that covers report creation, user management, tenant provisioning, and scheduled export configuration? If you want to automate tenant setup as part of your customer onboarding workflow — rather than manually configuring each new customer in the analytics admin — you need an API that supports it.

The Semantic Layer and Your Data Model

Connecting the platform to your database is step one. Making your data model usable in reports without requiring your customers to understand your schema is step two — and it's where the semantic layer matters.

A semantic layer sits between the raw database and the report builder. It translates your tables and columns into business terms your customers understand: "Revenue" instead of txn_amt_net, "Active Customers" instead of a join across three tables filtered by status code. Report builders that expose the raw schema require your customers to understand your database — which most of them don't and shouldn't have to.

When evaluating platforms, ask: how is the semantic layer configured, and does it survive schema changes? In a well-built platform, a renamed column in your database requires one update in the semantic layer — not a fix in every report that references it. In a poorly-built one, schema changes break reports directly, and fixing them requires editing each report individually.

The Architecture Compatibility Checklist

Any "no" in this checklist is a potential blocker — not a nice-to-have gap. Architecture mismatches that surface after a signed contract are expensive to resolve and sometimes impossible without a platform change.