Run this Supabase dependency audit before the next reprice

If Supabase is your data layer, the next decision is whether to stay, negotiate, or prepare an exit before pricing follows the pivot. Supabase closed a $150 million venture round on October 2, 2026. It entered an agreement to buy Turso, a database company, without disclosing the purchase price.

Supabase is adding more than 1 million new users and 4 million new databases each month, and 70 percent of those new databases are attributed to agents or AI-driven tools. Glauber Costa, founder of Turso, will take the Supabase role of Head of Agentic Services, with Pekka Enberg and the Turso team joining him.

GIC led the round, with CapitalG, IronArc, and SquarePeg participating. The raise came four months after an earlier $500 million Series F. The proceeds are earmarked for employee liquidity and for building new AI-agent capabilities.

Agent growth changes the pricing risk

For a product that uses Supabase as its data layer, the question is whether the convenience is priced for the workload you actually run. If your product is not agent traffic, the growth metrics are a warning, not a promise. The database may keep working, while the cost model moves toward the workload that now dominates new creation.

The same convenience that saves setup time can become a visible cost when the vendor changes its emphasis. A data layer is a good place to move fast, but it is also a place where price changes reach the product. For human-facing workloads, the agent mix signals a shift in platform incentives. For agent-facing workloads, the same shift may be a feature, not a threat.

Four checks separate convenience from structural dependency

The four checks below are the part you keep. Each item is a quick test, and the order moves from what you run to what you would have to move. Run them to separate a convenience from a structural dependency before the next price change makes the choice for you.

You do not need a full architecture review to run it. You need a current view of what touches the database, a current view of what the database costs, and a rough sense of what would have to be rebuilt. The audit is a decision tool, not a migration plan. It tells you when to start the migration conversation, not how to execute it in production.

• Center of gravity. Identify the tables, queues, auth flows, and background jobs that would break first if the database moved. When the answer is your core product loop, the dependency is structural.
• Pricing fold-in. Estimate the current monthly cost as a share of revenue and as a share of gross margin. A modest reprice that moves the number into a visible line item is real exposure.
• Migration distance. Count the custom queries, extensions, access rules, file storage, realtime connections, and serverless functions that would need rework. A high count makes the exit a project, not a switch.
• Data gravity. Ask what the data is worth to you, not just what it costs to move. When the data is the product, the migration cost is a constraint, not a detail.

Write the answers down. A dependency that feels small in the moment can become a line item when the next price change lands. The audit gives you a checkpoint to revisit the question, and a reason to treat the data layer as a cost center with an exit option.

Use the result to set an exit budget

If the early checks point to a structural dependency and visible cost exposure, the audit has done its job. You now have a reason to price the exit before the vendor prices the entry. The next step is a budget line, not a hope that pricing stays flat.

For workloads that are not agent traffic, the audit is a vendor lock-in check. It turns a convenience decision into a budget decision before the next reprice.