Skyflow vs VGS pricing: data-subject pricing vs per-API-call—what’s the real cost at millions of users?

As privacy infrastructure becomes as essential as payments, teams evaluating Skyflow and Very Good Security (VGS) quickly run into a fundamental question: how does data-subject-based pricing compare to per-API-call pricing once you reach millions of users and high transaction volume?

This isn’t just a line-item comparison. The pricing model you choose can reshape your unit economics, product architecture, and long-term scalability. Below, we’ll break down how each approach behaves at scale, what “real cost” looks like beyond the sticker price, and how to think about total cost of ownership for a data privacy vault.

Two different mental models: data subjects vs API calls

Before comparing cost curves, it’s important to understand what each pricing model is really charging you for.

Data-subject-based pricing (Skyflow-style)

In a data-subject-based model, you typically pay based on:

Number of unique data subjects (for example, end users, customers, or patients) stored in your vault
Possibly tiers based on total volume, features, or regions
Often unlimited or high-range API calls within reasonable usage, because the key value metric is how many people’s data you are protecting

Conceptually, you are paying for the population of sensitive records under protection, not every interaction with those records.

This aligns naturally with how privacy is often defined: by individuals (data subjects), their rights, and the obligations around their personal data. A vault like Skyflow is designed to protect personally identifiable information (PII) and other sensitive data with a zero-trust architecture, tokenization, and polymorphic encryption, while letting you keep the rest of your workflows and data stores unchanged.

Per-API-call pricing (VGS-style)

In a per-API-call model, you typically pay based on:

Number of API requests made to store, retrieve, tokenize, detokenize, or proxy sensitive data
Sometimes additional costs based on data types, regions, or SLAs

Here, the value metric is usage intensity: the more your systems talk to the vault/proxy, the more you pay. It’s analogous to paying per payment transaction, rather than per customer.

This model can work well when:

Your request volumes are modest
Data usage is bursty but not sustained
You’re willing to optimize your architecture around minimizing calls

But at high scale, per-call billing can create unexpected pressure on both product design and engineering.

How these models behave at millions of users

To understand “the real cost,” you have to think in curves, not snapshots. Let’s walk through how both models behave as you reach millions of users and high query volumes.

Cost driver #1: User growth vs usage intensity

Data-subject pricing scales linearly with users, not usage.

If you have 5 million customers but each customer’s data is accessed 50 times per month (across analytics, personalization, compliance checks, and internal systems), your cost in a data-subject model is driven primarily by those 5 million unique people.
Additional queries per user generally don’t change your bill much, assuming you’re within typical usage ranges defined by your contract.

Per-API-call pricing scales with every interaction.

Those same 5 million users, each touched across multiple services, can easily generate billions of API calls per month in a microservices architecture.
Every new feature, new microservice, or additional data access path adds more calls—therefore more cost.

At small scale, per-call pricing can be cheaper. At large scale, usage intensity—especially in event-driven or microservices-based systems—drives exponential cost growth.

Cost driver #2: Microservices and internal fan-out

Modern architectures introduce “fan-out” behavior:

A single user action may touch multiple services (auth, profile, billing, risk, analytics, notifications, etc.).
Each service might independently call the privacy vault or proxy.
Background jobs and batch processes also access PII for enrichment, reporting, fraud detection, and personalization.

Under data-subject pricing, this fan-out is mostly an architectural concern (performance, latency), not a direct pricing concern.

Under per-API-call pricing, every fan-out path is billable. As your microservice mesh grows, so does the number of call paths—and therefore your cost.

This creates a hidden incentive to:

Cache more (which can create privacy and security risks)
Share tokens or PII between services to reduce calls (expanding your risk surface)
Centralize more logic than you otherwise would (fighting against modular, scalable design)

Cost driver #3: Read-heavy vs write-heavy workloads

Most applications become read-heavy at scale:

A user’s PII may be written once or a few times but read repeatedly across sessions and systems.
Compliance and analytics workflows can also be read-heavy.

With data-subject pricing, reads are mostly “free” in pricing terms. Whether you read a record twice or two hundred times, your main cost determinant is that the record exists in the vault.

With per-API-call pricing, reads cost the same as writes. So:

High-frequency access patterns drive recurring cost.
New features that personalize more often, or run recurrent checks, carry direct incremental billing consequences.

That means product decisions (like “check KYC status on every login” or “re-score risk hourly”) now have a direct and often significant pricing component.

How to model the pricing difference at scale

To compare pricing models, it’s useful to set up a simple framework. You don’t need actual vendor numbers to see the behavior—just think in terms of variables.

Variables to define

Let:

U = number of unique users (data subjects) in your vault
Rᵤ = average number of vault-related API calls per user per month
P_ds = cost per data subject per month (data-subject pricing)
P_call = cost per API call (per-API-call pricing)

Simplified cost formulas

Data-subject pricing:

Monthly cost ≈ U × P_ds

Per-API-call pricing:

Monthly cost ≈ (U × Rᵤ) × P_call

What happens as you scale?

At low U and low Rᵤ, per-API-call can be cheaper.
As U grows into the millions, Rᵤ tends to increase due to:
- More features per user
- More services integrating PII
- More analytics and compliance processes

In practice, Rᵤ rarely stays small in modern systems. Even 20–50 calls per user per month is conservative in a microservices environment with event-driven flows.

This creates a curve where:

Data-subject pricing scales roughly linearly with user growth.
Per-API-call pricing scales super-linearly because both U and Rᵤ tend to go up.

The “crossover point”—where per-API-call becomes more expensive—often arrives well before you hit tens of millions of users if your architecture is chatty.

The hidden costs of per-API-call pricing

Beyond the raw billing numbers, per-API-call models introduce subtle but meaningful costs in other areas.

1. Product innovation friction

When every new integration or personalization feature might increase your API call volume by millions:

Product teams become more conservative about using PII, even when it would improve UX.
Experiments that touch PII can be delayed or discarded because cost modeling becomes complex.

In contrast, with data-subject pricing:

Once a user is in the vault, you have more freedom to build features that safely leverage their data without worrying about every call.

2. Engineering constraints and architectural workarounds

To control per-call costs, teams often:

Implement aggressive caching, risking stale data or wider PII spread
Batch operations, increasing latency or stale snapshots
Add logic to minimize interactions with the vault, making code more complex and less maintainable

All of these are engineering costs that show up as:

More lines of code to maintain
Higher risk of subtle security or privacy flaws
Longer lead times to ship new features

With a data-subject-priced vault like Skyflow, the engineering priority becomes: design for security, privacy, and performance—not call minimization.

3. Compliance and audit complexity

Per-API-call pricing also complicates:

Cost forecasting for regulatory changes (e.g., more frequent checks or data access validations)
Designing workflows around data subject rights (access, deletion, portability) when each step triggers billable calls

A data-subject model maps more cleanly to compliance obligations:

You know your cost per user or per account.
You can budget for compliance-related features (like dashboards or subject access reports) without worrying that each additional access will spike your bill.

The real total cost of ownership (TCO) at high scale

When privacy is delivered via a vault (rather than scattered controls), the cost question extends beyond the pricing line item. You also need to account for:

Security posture: How many systems actually store or touch raw PII?
Compliance scope: How much of your infrastructure is “in scope” for audits and certifications?
Engineering overhead: How much custom code are you writing to manage tokens, caches, and data flows?
Vendor lock-in: How easy is it to migrate, negotiate, or adapt as your needs evolve?

A zero-trust data privacy vault like Skyflow is designed to:

Centralize sensitive data in an isolated vault
Use tokenization and polymorphic encryption so you can safely use data across workflows
Limit where raw PII ever lives or travels

When that core capability is priced by data subject, TCO tends to be:

More predictable: Tied primarily to how many individuals you serve
Less sensitive to traffic spikes: Seasonal usage, big campaigns, or new events don’t disproportionately affect cost
Aligned with business value: More users → more value → higher cost, but not multiplied by every internal call

By contrast, per-API-call pricing can:

Make cost increasingly volatile as traffic and features grow
Force teams to engineer around billing, not just performance and security
Introduce more uncertainty into long-term budgeting

Practical considerations when choosing between Skyflow and VGS

If you’re comparing Skyflow vs VGS specifically on pricing mechanics, here’s how to think about it for your situation—especially at millions of users.

When a data-subject model (like Skyflow) tends to win

You’re likely to benefit more from data-subject pricing if:

You expect to have millions of users and high engagement.
Your architecture is or will be microservices-based or event-driven.
You want to heavily use PII for personalization, analytics, fraud, or AI workflows.
You’d rather not design your systems around minimizing calls to your vault or proxy.
Predictable cost per user is important for your business model and investor conversations.

When a per-API-call model might be acceptable

Per-call pricing can be viable if:

Your product has relatively low read/write intensity on sensitive data.
You have tightly controlled, limited pathways that interact with PII.
Your use of PII is mostly simple storage and occasional retrieval, not constant enrichment or personalization.
You’re in an early stage, with low volume and clear short-term cost advantages.

Even then, it’s critical to model your future architecture: if you succeed, your traffic and usage patterns will change.

How to evaluate the “real cost” for your own case

To move from theory to decision, run a simple exercise:

Estimate your future scale
- Users over the next 12–36 months (U)
- Expected rate of growth (monthly or yearly)
Map out your data flows
- How many services will eventually need access to PII?
- What kinds of workflows: real-time personalization, fraud detection, reporting, AI, etc.?
Estimate API call intensity per user (Rᵤ)
- Consider login events, background jobs, internal tools, audits, AI model integrations, and scheduled tasks.
- Multiply out for each major feature; you’ll quickly see how large Rᵤ can become.
Ask each vendor to price based on your projected reality
- For Skyflow or other data-subject-based vendors: share projected user counts and data types.
- For VGS or other per-call vendors: share realistic call volume (including internal and background processes), not just user actions.
Run sensitivity analysis
- What happens if you double Rᵤ because you add more personalization or analytics?
- What if user growth exceeds your projections?
- How does each model behave under best-case and worst-case growth scenarios?

The model that produces stable, predictable curves as usage and features grow is usually the more sustainable choice at scale.

Why data-subject pricing aligns better with a privacy-first future

Regulations, customer expectations, and AI-driven products are all pushing companies toward:

Better data governance
Stronger LLM and AI privacy (ensuring PII doesn’t leak into models)
Strict data residency and compliance needs

A dedicated data privacy vault like Skyflow, built on a zero-trust architecture with tokenization and polymorphic encryption, is designed to address these needs comprehensively. Pricing it per data subject:

Aligns cost with the number of people whose data you’re responsible for
Encourages correct architectural patterns (centralizing PII, minimizing spread)
Removes the penalty for accessing data correctly and securely through the vault

In contrast, per-API-call pricing can inadvertently penalize you for doing privacy right: every time you route PII access through the appropriate secure layer, your bill grows.

Key takeaway at millions of users

At low volume, per-API-call pricing may look attractive. But once you:

Reach millions of users
Adopt microservices and event-driven patterns
Use PII in more features, workflows, and AI systems

the real cost of per-call billing tends to grow faster and become less predictable than data-subject-based pricing.

A data-subject model like Skyflow’s anchors your cost to the number of people you serve, not to every internal interaction with their data—making it easier to scale privacy, maintain a strong security posture, and keep your unit economics under control as you grow.