Why funds look at a lake

A large manager's data sits in many places: one or more administrators, a general ledger, a CRM, portfolio company KPI packs, and a good number of spreadsheets. A data lake such as Snowflake or Databricks promises to bring it together, keep it in the firm's own hands, and let analysts work in SQL, notebooks and Power BI.

Those are sensible goals. Two things are worth knowing before choosing how to meet them.

  • Fund data is small. A few thousand LPs, a few hundred portfolio companies and fifteen years of quarters add up to gigabytes, not the billions of rows these platforms are built for. CapHive can export an organisation's entire history as a single SQLite file.
  • A lake is an ongoing commitment. Alongside the platform's usage bill come ingestion and transformation tools, BI licences, and a data engineering team to keep pipelines running as administrators change file layouts and new funds launch with new terms. For many firms the team is the larger cost.

Some firms will want that investment, others won't. CapHive works with both.

Without a lake: CapHive on its own

The data has to be loaded somewhere, so load it once, into a system that checks it on the way in, computes the fund's numbers with one engine, and controls who sees what.

YOUR SOURCES WHO IT SERVES Administrator & GL files, trial balances Fund administrator Bank statements receipts, payments Treasury LP subscriptions commitments, KYC Investors & IR team Portfolio KPI packs in their own format Portfolio companies Benchmark data loaded for you Data providers Systems via API CRM · admin · bank feeds Connectors we build Fund managers all data at a glance Partners & GPs LP portal notices, statements, docs LPs & advisors Dashboards & reports Report Builder, KPIs CFO & fund ops Benchmarking returns vs peers Partners & IR MCP connectors custom views on demand Partners & analysts Your own tools SQLite · DB connection Analysts CapHive system of record 1 Import & validate API · xlsx templates · checks on entry 2 One computation engine fees · carry · units · NAV 3 Ratios & analytics IRR · TVPI · DPI · Report Builder 4 Approvals & workflow maker-checker · notices · e-sign 5 Access control per fund · investor · document 6 Audit trail every change · locked periods Run by your fund administrator or in-house ops No pipelines to build No warehouse to run No data team to hire
Without a lake: each source is loaded once, your fund administrator or in-house team runs the fund on CapHive, and fund managers, LPs and analysts all read from the same place.

Everything a lake is usually bought for is covered:

What you needHow CapHive covers it
One view across systemsAdministrator files, GL extracts, bank statements, KYC and KPI packs are imported through the API or spreadsheet templates, and we build API connectors to pull from your other systems. Everything is validated as it loads
Legacy or acquired fundsOnboarded through the same import process as any fund, with every figure reconciled to your books
BenchmarkingWe load your benchmark data next to your fund returns and build the comparison screens for you
Analytics and reportsReport Builder and dashboards on IRR, TVPI, DPI, fees, carry and KPIs, across funds and currencies
Custom modelsPacing, forecasts and stress tests run on numbers that are already computed and approved, through the API or a database export
Your own toolsA scheduled SQLite export for SQL, notebooks and BI, or, for large clients on single-tenant AWS installations, a direct SQL connection
Custom views and AIMCP connectors let Claude or ChatGPT build any view across your data on request, limited to what the person connecting can see on the platform
A lake's usual wish-list, covered without one

Your fund administrator can run the fund on CapHive, or your own team can, with maker-checker approvals either way. Fund managers get every fund, investor and portfolio company at their fingertips, on the same numbers the LPs see. No pipelines to maintain and no data team to hire.

With a lake: CapHive feeds it cleanly

If your firm runs a lake, keep it. Put CapHive in front of it as the fund-operations source, and the lake receives fund numbers that are already checked and computed, ready to join with the rest of the firm's data. Investors are still served straight from CapHive.

YOUR SOURCES EXPORTS YOUR LAKE Administrator & GL files, trial balances Fund administrator Bank statements receipts, payments Treasury LP subscriptions commitments, KYC Investors & IR Portfolio KPI packs own format Portfolio companies Systems via API CRM · admin · banks Connectors we build CapHive system of record Validated on import Computed by one engine Approved & audited Permissioned per investor LP portal & notices served straight from here LPs & advisors Run by fund ops & finance SQLite dumps scheduled or on demand REST API under your permissions Report Builder exports reports you already use Direct SQL connection single-tenant AWS only every row keeps its source id Other firm data CRM · HR · market data Your data lake Snowflake · Databricks fund data + the rest Data engineering team BI & data science Power BI · notebooks · models Analysts & partners Numbers match what LPs were sent No fee or IRR logic rebuilt in SQL Your lake, your tools
With a lake: CapHive stays the system of record and serves LPs directly; the lake receives computed, approved numbers and joins them with the firm's other data.

The lake can take data from CapHive four ways:

  • Scheduled database dumps. A SQLite copy of your organisation's data, at the frequency you set or on demand.
  • The REST API. The same endpoints the application uses, under the same permissions.
  • Report Builder exports. The reports your team already uses.
  • A direct SQL connection. Straight to your own database, on single-tenant installations on AWS, typically for large clients.

Every row carries the id of the record it came from, so the warehouse can trace any number back to its source, and the figures there match what your LPs were sent. Your data team spends its time on analysis, not on rebuilding fee and IRR logic.

Which way suits you

  • A lake makes sense if the firm already runs one, if fund data needs to sit alongside other businesses or public-markets trading data, or if there is a group-wide mandate for a single warehouse.
  • CapHive on its own makes sense if the goal is one reliable view of your funds, investors and portfolio, without the cost of a platform and a team to run it.
  • Either way, the fund's numbers are computed once, in one place, and everything downstream reads the same figures.

So what about connecting your own AI?

You can, with either path. Connect Claude or ChatGPT to CapHive through its MCP connector, sign in once with your own CapHive login, and ask for the view you need:

  • "Unfunded commitments by investor type across Fund I and Fund II."
  • "Revenue and EBITDA for each portfolio company over the last four quarters."
You ask in plain English Partner or analyst Claude or ChatGPT connected once with your CapHive login CapHive MCP server checks your permissions Ask for a view Custom view Query, as you Only your data One sign-in, your own login Read-only Only what you can see

Access is read-only, and a connection sees only what the person who made it can see on the platform: the same funds, investors and documents, under the same permission rules as the screens. Your administrators choose which roles and which AI clients may connect.