A cloud analytics platform needed to replace its third-party driver while keeping existing reporting tools working. CLOUDSUFI built a connectivity layer that preserved required functions and comparable metadata performance, while giving the platform team control over fixes and releases.
Open Database Connectivity, or ODBC, is a standard middleware layer. It lets applications such as Power BI, Tableau, and Excel connect to different databases through one consistent interface. Without this standard layer, each application would need a separate integration for every database or analytics platform. ODBC standardizes the process, so enterprise applications can send queries and receive data through one common set of specifications.
For the platform provider, the driver affects query speed, application compatibility, metadata discovery, and secure access. It also affects how the platform handles large result sets.
Enterprise users judge analytics platforms by the tools they use every day. The data platform may process large workloads, but its connectivity layer can still slow the flow of data into reporting and analytics applications.
Google needed a new ODBC driver for BigQuery. It had to match the market-leading driver’s functions, improve normal data-fetch performance, and give Google more control over bug fixes, release timing, and future improvements.
The goal was to replace an established market standard without losing compatibility. BigQuery supports analytical work across large and complex datasets. The existing Simba driver had mature functions and broad compatibility, but its normal data-fetch path was not optimized for modern analytical workloads at this scale. Traditional transfer methods added processing overhead, and the effect was greater when large result sets had to be parsed and moved through text-heavy interfaces — slowing reports and making applications less responsive.
Google also depended on Simba’s development and release schedule for fixes and improvements. When teams found a bug, compatibility issue, or performance concern, Google could not always resolve or release the change on its own.
The technical requirements were clear: support the ODBC API coverage expected by existing users, preserve compatibility with major analytics and reporting applications, translate cloud-native data types into standard ODBC formats, improve throughput for large analytical result sets, keep metadata calls responsive, and meet enterprise security, memory-safety, and concurrency requirements.
“The challenge was not simply to build another connector. We had to match the functional coverage of a mature market leader while redesigning the data path for cloud-scale workloads. The result was stronger data-fetch performance without compromising metadata handling, compatibility, or system reliability.”
Technical Leader Perspective
Performance engineering and compatibility
CLOUDSUFI built a custom ODBC driver for BigQuery with modern C++. It retained the ODBC API coverage supported by the incumbent driver while improving data-fetch performance and giving Google direct control over the product roadmap.
Six core engineering components carried the work. An application compatibility and ODBC API layer preserved the functions expected in existing enterprise analytics workflows. Query and function translation converted application requests into execution patterns BigQuery could process. Schema and data-type mapping translated cloud-native BigQuery structures into standard ODBC representations. Adaptive workload routing sent small metadata calls and large analytical workloads through different paths. High-throughput binary data transfer reduced text-heavy parsing overhead for large result sets. System hardening integrated authentication, encryption, automated testing, and build controls.
Five decisions shaped how the driver performs. C++ gave the driver low-level memory control, reducing runtime overhead and supporting efficient binary data handling. Feature parity came before expansion — matching established ODBC API coverage reduced adoption risk and preserved essential functions. Binary streaming replaced text-heavy response processing for large result sets, reducing parsing work and improving transfer speed. Separate execution paths kept small metadata calls lightweight while routing larger queries through a high-throughput path. Quality controls were embedded throughout delivery: unit tests, memory-safety checks, concurrency validation, static analysis, and strict build controls.
The new driver was benchmarked against Simba, the established market leader and the existing reference point for BigQuery ODBC connectivity. Internal benchmark comparisons across key workload types showed the new driver retrieving normal data about 20% faster, with metadata operations performing on par with Simba. The improvement applies only to normal data-fetch workloads — metadata operations remain comparable to the market leader, keeping catalogue, schema, and discovery requests responsive. This comparison is illustrative, based on internal benchmark results; final benchmark methodology should be confirmed before publication.
The result: approximately 20% faster normal data retrieval than Simba, metadata APIs performing on par with Simba, required feature coverage maintained, and direct control over fixes, optimization, and release timing.
The engagement changed the architecture and the operating model. The driver is a platform connectivity capability, not a standalone end-user product — its strategic value comes from the workloads it enables and retains.
The business and strategic impact: an improved experience for analysts using familiar reporting tools, reduced friction when teams work with large datasets, faster responses to compatibility and support needs, more control for the platform team over product priorities and optimization, and stronger support for cloud migrations and workload retention.
Better connectivity improves the full analytics experience. It reduces friction for large analytical workloads, and it gives the platform team more room to improve performance, compatibility, and customer support over time.
“The real value of this work goes beyond performance. Owning the driver gives us direct control over fixes, release timing and future improvements. That means we can respond to customer needs faster, reduce dependency on an external roadmap and improve a critical part of the analytics experience.”
Business/Product Leader Perspective
Product ownership and release control
Let's build what's next.
Talk to us about your data and AI challenges — and how CLOUDSUFI can help solve them.
Talk to us →By submitting, you consent to CLOUDSUFI processing your information in accordance with our Privacy Policy. We take your privacy seriously; opt out of email updates at any time.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
