Connects to your existing application database.
Yurbi queries your SaaS product's database directly — tables, views, stored procedures, or raw SQL. No ETL pipeline. No data migration. No copy of your data sitting somewhere else. The closer Yurbi is to your source, the faster your reports render.
- Native drivers — no third-party middleware
- Direct queries to your tables, views, or stored procedures
- Read-only access — Yurbi never writes to your application data
- FastCache layer for high-performance reporting at scale
Built-in drivers for the databases SaaS products actually run on
No ODBC setup, no third-party middleware. Native database drivers for the engines most ISVs and SaaS products use — fast, reliable, and maintained as part of the Yurbi platform.
Running on AWS, Azure, or GCP? Same native drivers.
Cloud-managed database services are just managed versions of the same engines. If your SaaS product runs on RDS, Azure SQL, or Cloud SQL, Yurbi connects with the same native driver — no additional setup.
-
Amazon RDS MySQL, PostgreSQL, SQL Server, MariaDB, Oracle on RDS
-
Amazon Aurora Aurora MySQL-compatible & Aurora PostgreSQL-compatible
-
Azure SQL Database Fully managed SQL Server engine in the cloud
-
Azure SQL Managed Instance Near-100% SQL Server compatibility, fully managed
-
Azure Database for PostgreSQL Flexible Server and single server
-
Azure Database for MySQL Flexible Server
-
Cloud SQL MySQL, PostgreSQL, and SQL Server on Cloud SQL
-
AlloyDB PostgreSQL-compatible, high-performance
The closer to your data, the faster the report
Yurbi doesn't require you to restructure your database. Connect to your existing schema as-is and query it the way your team already understands it.
Tables & Views
Connect directly to your application's tables or database views. Views are particularly powerful — pre-join your complex schemas once, then let business users query them without touching raw tables.
Stored Procedures
Run existing stored procedures and surface their results as reports. Ideal when your data logic is already optimized and maintained inside the database — Yurbi calls it, you report on it.
Custom SQL Queries
Write raw SQL queries directly in Yurbi — joins, subqueries, aggregates, window functions. Full SQL flexibility for complex reporting scenarios your schema requires.
FastCache
In-memory caching layer that runs expensive queries once and serves subsequent requests from cache. Essential for multi-tenant reporting at scale — your database doesn't get hammered every time a customer loads their dashboard.
Other data sources via ODBC
If your application data lives in a cloud data warehouse or another engine, Yurbi can connect via ODBC. You configure and manage the driver on your self-hosted server.
Beyond direct database connections
For large-scale internal reporting use cases, Yurbi supports additional data source types. These are best suited for supplemental reporting scenarios — not primary embedded analytics pipelines.
API Data Sources
Yurbi can fetch data from REST API endpoints and store the results for reporting. This is a fetch-and-store model — not real-time API querying. Scheduled fetches populate a local data set that Yurbi reports against.
Excel & CSV Import
Upload spreadsheet files and import them as queryable data sets. Useful for supplemental reference data or one-off reporting needs where a database connection isn't available.
One ISV product. One brand. One primary database schema.
Yurbi is licensed per ISV product — not as an unlimited data integration platform. Each plan covers one application, one brand, and your product's primary database schema. This keeps the licensing model predictable and aligns with how ISVs actually deploy embedded analytics.
Running more than one product? Multiple products qualify for a meaningful discount. Need to connect to additional schemas or deployments? See how that works →
Integration questions, answered plainly
No. Yurbi connects to your existing database schema as-is. There's no ETL pipeline to build, no data warehouse to populate, and no schema changes required. We query your tables, views, stored procedures, or custom SQL exactly as they exist today. The most common setup is pointing Yurbi at a read replica or a dedicated reporting database to keep load off your production system.
Yes, fully. RDS and Aurora are managed versions of the same database engines — PostgreSQL, MySQL, SQL Server, MariaDB, and Oracle. Yurbi uses the same native driver regardless of whether you're running managed cloud or on-premise. You provide the connection string, credentials, and whitelist Yurbi's server IP. Connection setup typically takes minutes.
Yes. Azure SQL Database and Azure SQL Managed Instance use the SQL Server driver — the same native driver Yurbi includes for on-premise SQL Server. Azure Database for PostgreSQL and Azure Database for MySQL use their respective native drivers. If you're on an Azure stack and evaluating Yurbi, this is a common setup — book a demo and we'll walk through the connection specifics for your configuration.
Yurbi's own backend — the database it uses to store reports, configurations, and user data — runs on either PostgreSQL or Microsoft SQL Server. For production deployments at scale, SQL Server handles concurrency particularly well and is the more battle-tested choice for multi-tenant workloads in the Yurbi context. PostgreSQL works and is fine for smaller deployments or teams that strongly prefer it. If you're on an embedded PostgreSQL setup and growing fast, it's worth a conversation about migrating to a dedicated SQL Server backend.
Both work. Views are often the cleaner long-term approach — you pre-join complex schemas and apply business logic once in the database, then let Yurbi report against a simpler surface. This keeps your report definitions stable when underlying table structures change. Direct table access with custom SQL or stored procedures is better when you need fine-grained control over query behavior or when your DBA team manages query optimization at the database level.
Yurbi uses a relational query model — we generate SQL and run it against your data source. MongoDB Atlas has an ODBC driver that exposes a SQL interface, so basic connectivity is possible. However, if your data is deeply nested or document-oriented and your reporting requires complex joins or aggregations, performance at scale is not ideal. The honest answer is: it depends on your specific schema and what you need to report on. Talk to us before you assume it won't work or that it will work perfectly.
No. Yurbi only needs read access to your application data source. We strongly recommend connecting with a read-only database account — this is best practice and ensures Yurbi can never modify your application data. The only database that Yurbi writes to is its own backend database (PostgreSQL or SQL Server), which stores reports, users, and configuration — completely separate from your application data.
FastCache is Yurbi's in-memory caching layer. When multiple tenants run the same or similar reports against large datasets, FastCache serves repeat requests from memory rather than re-running the database query each time. This is especially important for multi-tenant ISV deployments where 50+ customers might load dashboards around the same time. FastCache is included in all plans — you don't need to configure anything, it works automatically where applicable.