The Data Stack Problem at Every Funding Stage

Every data team eventually hits the same wall: the team that built the data platform isn't the team running it day to day. That gap shows up at Series A, Series B, Series C, and inside regulated industries from day one. It compounds as you grow. The shape is different at each stage. The cost of ignoring it gets bigger.

The customer-style quotes throughout this post are composites distilled from conversations we've had with heads of data and platform engineers. They're illustrative of the pattern, not direct transcripts.

Series A: One person owns everything

At Series A, you've raised your first institutional round and you're proving out GTM. You hired a couple of data people. There may be an infra team, but nobody dedicated to data infrastructure. The stack is the simplest possible thing that works. Often there isn't even a data warehouse yet: analytics run straight against a read replica of the production database (hopefully a read replica, anyway, and not prod itself), or a standalone database (Postgres, MySQL, etc.) someone spun up. If there is anything more, it's an ingestion tool like Fivetran or Airbyte landing data somewhere central, transforms running as SQL (maybe dbt, often just views and scheduled queries), a BI tool plugged in at the end. Analysts can write SQL. The board gets a dashboard. Life is fine.

The Series A data stack works because it's simple. Someone pointed a BI tool at the prod replica, or wired up a query or two against a Postgres instance. The first hire who built all of it knows where every wire goes. Until they have to leave for a week, and everything breaks while they're gone.

There's no orchestration yet because the complexity doesn't demand it. A cron job or a scheduled query handles whatever transforms exist. This can work at this stage. But it's a ticking time bomb, and it goes off the moment pipelines get complex or a product change shifts an upstream schema. Nothing models the dependencies, catches the failures, or handles the conditional logic, so the breakage stays invisible until a data consumer notices that the once-pristine CEO dashboard is now wildly wrong, and nobody can say why.

The moment it changes

It usually starts with one ordering problem that the scheduler can't express:

"We have three data sources that all need to land before the morning transform runs. A scheduled query doesn't know about dependencies, so when one is late the dashboard silently ships yesterday's numbers. We've started babysitting it by hand. Someone has to be the one watching every morning."

The typical Series A stack

| Layer | Tool | Who owns it | |---|---|---| | Source data | Prod read replica or standalone Postgres/MySQL | Software engineering team | | Ingestion | None yet, or Fivetran/Airbyte if anything | First hire | | Warehouse | Often none yet; Snowflake or BigQuery if anything | First hire | | Transform | SQL views and scheduled queries (maybe dbt) | First hire | | Orchestration | Cron / scheduled queries | Nobody, really | | BI | Metabase, Tableau, or Looker | First hire + analysts | | Catalog | None yet | n/a |

What teams try first

Hire a second data engineer and split the load. This helps with bandwidth but not with the underlying ownership problem. Now two people share the on-call burden instead of one. The stack still doesn't have a real orchestration layer, and the first time one of them leaves the muscle memory leaves with them.

What's actually breaking

• One person holds all the knowledge. Vacation equals anxiety.
• No real orchestration. Pipeline failures get discovered by a stakeholder staring at a broken dashboard, not caught by monitoring.
• Querying the replica directly (hopefully the replica, not prod) works at this volume, but starts to strain the database as analytics grow — and the day someone runs an unindexed SELECT * against the wrong host, the whole app feels it.
• Per-row SaaS pricing (Fivetran), if you've adopted it, is fine now but compounds badly at Series B volumes.
• If you're in healthcare or fintech, data flowing through third-party SaaS is already a compliance exposure.

What SkaleData does at Series A

• Deploys the full stack in your cloud from day one: orchestration, ingestion, catalog, BI, all wired together.
• Operational knowledge lives with us, not in one engineer's head.
• If you're regulated, BYOC is architecturally compatible with HIPAA, SOC 2, and PCI from day one. You're not rearchitecting the data path at Series C when an auditor or enterprise buyer shows up.
• Pricing that doesn't compound against you as data volume grows.

SkaleData fit at Series A: Strong, especially if you're in a regulated industry from day one.

Series B: Either way, the data team is left holding it

By Series B you've raised a sizable growth round, scaled the GTM motion, and started moving upmarket. The data team has grown into a real team, several engineers deep. There's an infra team. Somebody (a new VP of Data, a board member who came from a bigger company) said the words: we need a real data platform. The infra team got the ticket. From here the story splits two ways, and both end in the same place.

Path one: the infra team builds it. They stand up Airflow on Kubernetes, wire in Airflow, configure the networking, get SSO working. A proper production-grade stack, several months of work. Then they hand it off and move on to the next project. This was the right call for the infra team — it's what infra teams do. But nobody asked who was going to own it afterward. The data team inherits a Kubernetes cluster they didn't build and can't confidently operate. That ownership question doesn't live in any ticket. It lives in the gap between two org chart boxes.

Path two: the infra team says no way. They're underwater on their own roadmap, and babysitting Airflow, Airbyte, and a catalog forever is not a fight they want. So they hand it back with a verdict: go buy managed services. Astronomer for orchestration, Fivetran/Airbyte for ingestion, a hosted catalog, a BI SaaS. Reasonable on its face — except now the data team is the systems integrator for half a dozen vendors, each with its own auth, its own bill, and its own opinion about how data should move. The glue between them, the part that actually breaks, belongs to no vendor. And every byte still flows through third-party infrastructure, which the compliance team will have feelings about by Series C.

Either path lands in the same spot: the data team owns operations it isn't staffed to run. One version is a cluster nobody wants to touch. The other is a vendor sprawl nobody fully understands. The wall is identical — the team running the platform isn't the team that should be.

The moment it changes

If the infra team built it, the patch treadmill is what wakes you up:

"Airflow released a security patch we need to apply. My data engineers can figure it out, but it's lost time that wasn't in anyone's sprint. The infra team is busy. This is going to keep happening every few months forever."

If you went the managed route, it's the integration seams and the invoice:

"Every tool works on its own. It's the handoffs between them that page us — a connector schema change Astronomer never hears about, an auth token that expired in the catalog. And the combined bill is now bigger than the engineer we'd have hired to run it ourselves."

The typical Series B stack

| Layer | Self-hosted path | Managed path | Who owns it now | |---|---|---|---| | Ingestion | Self-hosted connectors (e.g. Airbyte, Meltano) | Managed ingestion SaaS (e.g. Fivetran, Stitch) | Data team | | Warehouse | Cloud warehouse (e.g. Snowflake, BigQuery, Redshift, Databricks) | Same | Data team | | Orchestration | OSS scheduler on Kubernetes (e.g. Airflow, Dagster, Prefect) | Hosted orchestration (e.g. Astronomer, Prefect Cloud) | Data team (+ borrowed infra) | | Catalog | Self-hosted catalog (e.g. DataHub, OpenMetadata, Amundsen) | Catalog SaaS (e.g. Atlan, Collibra) | One engineer, mostly | | BI | Self-hosted BI (e.g. Superset, Metabase) | BI SaaS (e.g. Looker, Tableau, Power BI) | Data team | | Infrastructure | K8s, VPC, IAM, certs | Vendor accounts + the glue between them | Infra team (3 weeks out) / nobody |

What teams try first

If you self-hosted, you adopt Astronomer to take the Airflow maintenance off your plate. It works — Airflow ops are genuinely painful and Astronomer is a real product. But it solves one tool. You still own Ingestion, Catalog, Visualization, and Infrastructure. The gap narrows; it doesn't close. And now you're paying Astronomer's per-deployment and per-worker fees on top of your existing cloud bill.

If you went managed from the start, you keep adding vendors to fill the holes — a reverse-ETL tool here, an observability SaaS there. Each one is reasonable in isolation. Together they're a procurement problem, an auth sprawl, and a stack of invoices that quietly outgrows the salary of the engineer you were trying not to hire.

What's actually breaking

• Data engineers losing a meaningful share of every week to platform ops (or vendor wrangling) instead of pipeline work.
• Self-hosted: every IAM change, cluster resize, or cert renewal is a ticket to infra. And a two-week wait.
• Managed: the failures live in the handoffs between vendors, which no single vendor will own.
• One engineer holds all knowledge of how the stack fits together. They're getting recruiter calls.
• The 3am page goes to whoever is closest, not whoever is responsible.
• The combined SaaS bill is creeping past what a dedicated platform hire would have cost.

What SkaleData does at Series B

• One platform instead of a cluster you can't staff or a pile of vendor contracts. The full stack, wired together.
• We own the full ops layer: upgrades, incidents, cluster sizing, IAM, cert rotation. All of it.
• Your data engineers write pipelines instead of operating infrastructure — including the brittle handoffs between tools that today belong to no one.
• The stack stays in your cloud account, so data never flows through a third party's infrastructure. Infra team keeps visibility, loses the ticket queue.
• One predictable bill instead of a stack of per-seat, per-row, and per-worker invoices that compound as you grow.
• No knowledge concentration risk. Operational depth lives with us, not in one person's head.

SkaleData fit at Series B: Primary ICP. This is exactly the problem we're built for.

Series C: Governance is mandatory now

By Series C, you've raised a substantial late-stage round and you're either moving upmarket or pre-IPO. The data team is a sizable org now, maybe with a dedicated data platform role. The stack works, mostly. But there's a new set of problems on top of the old ones. Enterprise procurement requires SOC 2. An auditor wants to know where data flows. The board is asking about data governance.

Meanwhile, one engineer (the one who's been closest to the platform since it was built) has become the single person who understands how all of it fits together. That person knows which Airflow DAGs depend on which connectors. They know why there's a workaround in the DataHub ingestion YAML. They know which IAM role needs rotating every 90 days or things break quietly. They're also getting calls from every well-funded startup in the city offering them 30% more and a clean problem to work on.

The moment it changes

"We lost our key platform engineer last quarter. We've been in triage for three months. We thought we had documentation. We didn't have documentation. We had someone who knew where everything was and could explain it on demand."

The typical Series C stack

| Layer | Tool | Who really owns it | |---|---|---| | Orchestration | Scheduler, self-hosted or managed (e.g. Airflow, Dagster, Astronomer) | One engineer + vendor support | | Ingestion | A mix of self-hosted and managed connectors (e.g. Airbyte, Fivetran, Meltano) | Multiple owners, unclear | | Catalog | A catalog tool installed but not maintained (e.g. DataHub, OpenMetadata, Atlan) | Stale. Nobody's gardening it. | | Governance | Auditors asking questions | Everyone scrambling | | Compliance | SOC 2 in progress or required | Blocking enterprise deals |

What teams try first

Hire a dedicated data platform engineer ($200 to $350K total comp in major US tech hubs) to own the stack full time. This is the right instinct. It creates ownership clarity. But it creates a new single point of failure at a higher price point, and it doesn't fix the underlying architecture problem if the stack was built on hosted SaaS tools that now fail compliance review.

What's actually breaking

• One engineer holds all institutional knowledge. When they leave, you're starting over.
• DataHub is installed but nobody is actively maintaining it. Governance is theater, not reality.
• SOC 2 auditors and enterprise buyers want to know where data lives. "A third-party vendor's cloud" is the wrong answer.
• Data volume has 10x'd since the platform was built. Nobody right-sized the cluster, and every usage-based vendor invoice (per-row ingestion, per-worker compute, warehouse credits) has scaled right along with it. Things are noisy, and expensive.

What SkaleData does at Series C

• Operational knowledge lives across our team, not in one engineer's head.
• The catalog runs on the same cluster as the rest of your stack, not as a bolted-on SaaS. We keep the software itself current and healthy; and because it sits right next to your orchestration, ingestion, and warehouse, keeping lineage and metadata fresh is part of the workflow instead of a separate integration project. The catalog is yours to curate, but the stack makes curating it easy.
• BYOC gives you a clean data-residency answer: data lives in your account, full stop. The remaining compliance work (controls, audits, BAAs) is yours, but the architectural blocker is gone.
• Autoscaling is wired in from day one. We monitor cluster health and propose right-sizing when we see drift, instead of waiting for the noisy-neighbor incident.

SkaleData fit at Series C: Strong, especially for compliance readiness and removing key-person dependency.

Regulated industries: Data cannot leave your cloud

For companies in healthcare, financial services, insurance, and govtech, the standard managed-service path doesn't work. HIPAA, SOC 2, FedRAMP, PCI. The rules vary but the constraint is consistent: your data has to stay inside your cloud account. This isn't a Series-B-and-later concern. It's true from Series A.

To be clear, this isn't a knock on those vendors' security posture. Most of the major managed services are HIPAA-eligible, SOC 2 compliant, and will sign a BAA. The issue is architectural, not a question of whether the vendor is trustworthy: the default managed-service path routes your data through the vendor's cloud. Fivetran Hosted processes data through Fivetran's infrastructure. Astro Hosted runs your DAGs on Astronomer's servers. Fivetran's Hybrid Deployment and Astronomer's Astro Private Cloud exist for customers who push back, but those are enterprise-tier offerings most teams aren't on. The hosted path is what teams actually buy. And when your requirement is that data never leaves your account, no certification on the vendor's side changes the fact that, on that path, it does.

The typical response is to build it yourself. That solves the data residency problem but creates the full platform ops problem. Now you have a self-hosted stack with all the maintenance burden that comes with it, and no dedicated team to run it. You've traded one problem for another.

The moment it becomes unavoidable

"The enterprise prospect is asking where their data goes during ingestion. The honest answer is Fivetran's servers for a few seconds. That's enough to kill the deal or send it to a six-month security review. We need to fix the architecture before this happens again."

The compliance-safe architecture

| Layer | Tool | Data location | |---|---|---| | Ingestion | Airbyte (self-hosted in your VPC) | Your cloud, your VPC | | Orchestration | Airflow on Kubernetes (your cluster) | Your cloud, your VPC | | Catalog | DataHub (self-hosted) | Your cloud, your VPC | | BI | Superset (self-hosted) | Your cloud, your VPC | | Control plane | SkaleData (outside your account) | No data access, ops only |

What teams try first

Build and self-host everything. This is architecturally correct (data stays in your account), but it creates the full platform engineering burden. The stack needs Kubernetes expertise, ongoing maintenance, incident response, and someone who understands how all the pieces fit together. Most regulated-industry companies at Series A or B don't have that person. They're borrowing time from whoever is closest.

The compliance trap

• SaaS tools are fast to set up and usually compliant in their own right, but the hosted model routes your data through third-party infrastructure. When your mandate is data residency, that's a non-starter regardless of the vendor's certifications.
• Self-hosting solves compliance but creates a full ops burden. Who maintains the Kubernetes cluster?
• Rearchitecting a live production stack from hosted SaaS to BYOC takes six to twelve months.
• Every enterprise deal exposes the architecture. The longer you wait to fix it, the more deals it costs you.

The SkaleData answer

• Stack deploys into your VPC. Our control plane sits outside your account and never touches your data.
• Compliance answer is clean and auditable: data residency is your cloud account, full stop.
• You get the data residency of self-hosting without having to staff the ops team to maintain it.
• Start here at Series A. Don't rearchitect it at Series C when enterprise deals are on the line.

SkaleData fit for regulated industries: Purpose-built. We deploy into your VPC by default, not as an enterprise-tier upsell.

Where you are matters less than what comes next

The gap between the team that built your data platform and the team that uses it exists at every stage. At Series A it's one person doing everything. At Series B the infra team built it and handed it off. At Series C one engineer is the entire knowledge base. In regulated industries, the SaaS path was never available to begin with.

The stack runs in your cloud. The ops belong to us. Your data team does data work.

Request Early Access or book a demo and we'll show you what the deployment looks like in your account.