Ardent X OpenLedger

Summary:

OpenLedger added two new sources of financial data, migrated their data to a new schema while flattening JSON structures, and backfilled historical records

Results: Full migration completed in under a week, improved query performance, and new features built on top of new data with far less delay

Company:

OpenLedger offers embedded financial reporting & accounting APIs for SaaS platforms. They unify transaction, bank‐feed, invoice, and payment data into a unified ledger and provide dashboards, reconciliation, and real‐time financial metrics.

Problem:

• Existing flat schema was not meeting new use cases (e.g. breakdowns by merchant category, multi‐currency attributes, etc.).

• Historical data was inconsistent; newer fields missing in older records, making trend and dashboard computations fragile.

• Query latency and cost were increasing, especially for dashboards and downstream analytics involving complex joins and aggregations.

• Features could not be shipped as they depended on new data format and historical data to exist

Constraints:

• Must maintain data correctness during migration; dashboards & downstream systems should not break.

• Limited engineering time; needed a solution that would be safe, automatable, and low risk.

• Backfill needs to be efficient, must handle historical data volume.

• Tight latency SLAs for queries (dashboard refreshes, analytics jobs).

  
  

Approach:

1. Target model design
   Defined a unified, flattened schema for transactions, vendor and merchant details, multi-currency fields, and audit columns automatically with Ardent. Openledger can co-design their optimal data patterns with Ardent's understanding of the stack.

2. Pipeline buildout with Ardent
   Used Ardent to generate ingestion and transform steps, then plugged them into existing Airflow DAGs. PostgreSQL hosted the new tables, with safe DDL/DML rollout.

3. Historical backfill
   Backfilled legacy partitions in chunks to keep p95/p99 stable. Applied deterministic mapping rules and defaults for fields that did not exist historically.

4. Validation and pilot
   Reconciliation checks (totals, balances) and dashboard diffs ran on staging first. Null-rate and error-rate monitors were added before cutover.

5. Cutover
   Switched read paths to the new schema once checks passed. Retired legacy transforms and locked schema contracts.

Results

• Timeline: end-to-end source addition, schema migration, and backfill completed in under two weeks

• Quality: historical trend views stabilized; null-rates on new columns dropped after backfill

• Performance: flattened tables reduced query complexity and tail risk on key dashboards

• Ops: far less per-source glue code; a repeatable playbook for new sources

“We thought it would take us a whole month to migrate and backfill after introducing new data sources. Ardent built the pipelines and automatically backfilled all our data perfectly in days. In total”
— Pryce Yebesi, CEO, OpenLedger

Why Ardent

• Works with the existing stack (Airflow, PostgreSQL)

• Agentic “AI Data Engineer” that builds pipelines, manages schemas, and handles backfills

• Production-ready approach with secure handling and parallel execution

Takeaways for technical leaders

• If nested JSON and schema drift are hurting speed and reliability, flatten and unify first, then backfill to restore trends.

• You do not need a quarter-long rewrite. With the right platform and orchestration already in place, two weeks is realistic at meaningful scale.

• Measure tail latency and null-rates, not just averages. Those show the real improvement.