Data Panda lifts the JSON documents behind your mobile, web and IoT apps out of IBM Cloudant and into a SQL warehouse, on a schedule the business can trust. Once the document data sits next to your CRM, billing and accounting tables, dashboards, AI workflows and internal apps can all query it without a developer writing a one-off MapReduce view.
Cloudant started as Cloudant Inc., founded in 2008 by Alan Hoffman, Adam Kocoloski and Michael Miller out of the MIT physics department, with seed funding from Y Combinator. IBM announced the acquisition on 24 February 2014 and closed it on 4 March 2014, folding Cloudant into IBM Cloud as a fully managed JSON document database. The engine is based on the Apache CouchDB project and the BigCouch fork, which Cloudant donated back to Apache in 2016 to become CouchDB 2.0. Data is stored as schema-free JSON documents in databases, addressed by a document ID, and served over an HTTP/REST API that any language with an HTTP client can talk to.
Cloudant follows a master-less cluster model: every node accepts writes, and the same multi-master replication protocol that powers CouchDB and PouchDB sync handles the reconciliation. That makes it the default operational store for offline-first mobile apps, web apps and IoT devices that lose the network and reconnect later. On the indexing side, Cloudant ships MapReduce views for secondary indexes and aggregations, Cloudant Query for declarative JSON queries, Cloudant Search backed by Apache Lucene for full-text, and a geospatial index for location queries. The trade-off the IBM docs themselves call out: Cloudant is built for document operations and known access patterns, not for ad-hoc cross-database analytics. That is why most teams pair it with a warehouse: the live documents stay in Cloudant, and a sync (via the _changes feed or scheduled extracts) makes the same data joinable in SQL alongside the rest of the business.
Cloudant documents flattened into warehouse tables, joined to CRM and finance.
Let the Cloudant _changes feed trigger work across the rest of the stack.
Score offline-first app data with models without exporting documents by hand.
Admin tools on Cloudant data without exposing IBM Cloud API keys to the team.
A list of concrete reports, automations and AI features we have built on IBM Cloudant data. Pick the one that matches your situation.
How do we report on Cloudant without writing a custom MapReduce view for every question?
We do not push every business question back into Cloudant as a view. The default path is the _changes feed or scheduled snapshots landing in the warehouse, where business users query in SQL. Cloudant keeps serving the app, and the analytics work moves off it.
Our mobile app uses PouchDB to sync to Cloudant. Can the warehouse still see that data?
Yes. Documents that PouchDB clients sync up to Cloudant land in the same databases, and the warehouse follows the _changes feed from there. Mobile-originated activity ends up in the same SQL tables as everything else, with the originating client preserved as a field.
How are document conflicts from multi-master replication handled in the warehouse view?
The winning revision is loaded as the default record, and conflicting revisions are kept in a sibling table with the document ID and revision tree. Reporting sees one row per document, and ops can drill into conflict history when something looks off.
App-generated revenue and usage from Cloudant joined to the accounting ledger, without a developer running ad-hoc exports each month-end. Subscription and transactional revenue end up on the same customer record.
Product usage and feature adoption from the offline-first app on every CRM account. Reps see signals from Cloudant on their pipeline view in SQL, not in a JSON dump.
Cloudant throughput, storage growth, index usage and replication lag tracked alongside business KPIs. Cost per feature and tenant becomes a number finance can read, not an IBM Cloud console graph.
These are the 3 tables we currently pull from IBM Cloudant into your warehouse. Query them directly in SQL, join them to the rest of your stack, or build reports on top.
Missing a table you need? We can extend the sync. Tell us what is missing and we will build it for you.
You keep the reporting tool you already have. We connect it to the warehouse where your IBM Cloudant data lives.
OAuth authentication. Read-only by default. We sign a DPA and your admin keeps the keys.
Data flows into your warehouse on your schedule. Near real time or nightly, your call. You own the data.
We build the first dashboard, workflow or AI feature with you, then hand over the keys. Or we stay on for ongoing delivery.
We set up the foundation. Your team builds on top.
Best fit Teams that already have a BI analyst or data engineer and want to own the build.
We build the whole thing, end to end.
Best fit Teams without in-house BI or dev capacity. You tell us what you need and we deliver it.
You do. It lands in your warehouse, on your cloud account. We don't resell or aggregate it. If you stop working with us, the warehouse stays yours and keeps running.
Near real time for most operational systems. For heavier sources we schedule hourly or nightly. You pick based on what the reports need.
No. If you don't have one, we help you pick one and set it up as part of the first delivery. Common starting points are Snowflake, Microsoft Fabric, or a small Postgres start.
Both are supported. The _changes feed gives a near-real-time stream of document updates and is the default for databases where freshness matters. Scheduled snapshots are the pragmatic choice for large historical databases where a daily extract is enough. The two paths land in the same warehouse model.
Documents are flattened per field, with nested objects and arrays modelled as related tables. New fields appear as columns on the next sync, type changes are versioned, and renamed fields are mapped to their history so existing dashboards keep running.
We review your IBM Cloudant setup and the systems around it. Together we pick the first thing worth building.