Skip to content

Supabase is acquiring Turso. Read this if you build on your own.

13 min readSupabaseTursolibSQLPostgresDatabases

Short version: on October 2, 2026, Supabase announced it is acquiring Turso, the company that created libSQL, in the same breath as a new $150 million round. Both companies say nothing changes for existing users, and I believe them about this month. What changed is the map. The default Postgres for a new project now belongs to one of two very well funded companies, Neon inside Databricks and Supabase, and the best-known hosted SQLite just became a feature of one of them. If you build alone or on a small team, that concentration is the thing to plan around, because the people who get repriced first in a consolidated market are the ones with the least leverage.

I run Layerbase, which hosts both Postgres and libSQL, so I am a competitor and you should weigh everything below with that in mind. The facts are linked to their sources so you can check them without trusting me.

What was announced, and what was left out

The announcement came in three pieces: Supabase's post, Turso's post, and a press release covering the money.

  • Supabase raised $150 million led by GIC, with CapitalG, IronArc, and SquarePeg participating.
  • Supabase is acquiring Turso. Glauber Costa, Turso's founder, becomes Head of Agentic Services at Supabase.
  • Supabase's line for customers: "For existing users, nothing changes. Supabase will continue building around Postgres, while Turso will continue its work on SQLite."
  • Turso's version: "Turso keeps running. Your databases, APIs, and workflows continue as they do today," and "Turso Database remains open source and actively developed."
  • The stated reason is agents. The press release says Supabase adds more than 1 million users and 4 million new databases a month, and that 70% of those new databases are created by agents or AI-driven tools.

Now the parts that are missing, which I think matter more.

No price and no closing date. The wording is "is acquiring," and none of the three documents says the deal has closed or what it cost.

Nothing about pricing. Neither post says a word about what Turso Cloud plans will cost in a year, or whether the free plan survives in its current shape. "Nothing changes" is a statement about today.

libSQL is not mentioned. Turso's post promises that Turso Database, the Rust rewrite, stays open source. It does not contain the word libSQL. If you read libSQL vs Turso you know libSQL was already in maintenance mode, with new work going to the rewrite. The acquisition does not change that direction, and it does not reverse it either.

The upgrade path points one way. Turso's post describes "a clear graduation path. When SQLite isn't enough, you can move into standard Postgres through the Supabase ecosystem." Supabase's post says "SQLite is well suited to these small, on-demand workloads. Postgres is what you want as your application scales." Read those two sentences together. SQLite is now the top of a funnel, and the bottom of the funnel is a Supabase Postgres project.

Two companies now own the default

I want to be precise about the claim, because "monopoly" gets thrown around loosely. Supabase and Neon are not a monopoly on Postgres. AWS, Google, and Azure host far more of it than both combined, and Postgres itself is open source and belongs to nobody.

What the two of them hold is narrower and, for a solo developer, more important: the default. When a tutorial, a framework starter, or an AI app builder needs a database, it reaches for one of these two. Supabase now reports 13 million developers. Neon is what Vercel moved every Vercel Postgres store onto, and what its marketplace hands a new project. And the independent companies that used to compete for that same spot have been getting bought:

WhenBuyerBoughtReported price
May 2025DatabricksNeonabout $1 billion
June 2025SnowflakeCrunchy Data$164.5 million in cash per Snowflake's filings, widely reported as about $250 million (the record)
October 2026SupabaseTursonot disclosed

Eighteen months ago, a developer choosing a small managed database could pick between a focused serverless Postgres company, a focused Postgres-as-a-backend company, and a focused SQLite company, all independent and all competing for the same person. Today the first is a division of a data lakehouse vendor, and the third is about to be a division of the second.

That is why I think near-monopoly is a fair description of the on-ramp, even though it is the wrong word for the whole market. The check on a free tier or a $25 plan was never regulation. It was that a competitor would happily take the customer. Each of these deals removes a competitor who wanted that customer.

How Supabase's pricing got here

It would be easy to write this section as a story of price hikes. That is not what the record shows, and the real pattern is more useful to understand.

The headline price has barely moved. The entry paid plan has carried a $25 base for years, and it still does. What grew is the number of separate things that carry a meter.

  • August 2023: billing moved from projects to organizations. Supabase announced the change as "a major change, and we've tried to design it in a way that's cheaper for everyone." The plan fee is now charged once per organization, and compute is billed per project on top of it, with a $10 monthly compute credit that covers one of the smallest instances. Free accounts got a unified 5 GB of egress, and anyone with two free projects had to restructure them by the end of that October.
  • January 2024: IPv4 became an add-on. Direct database connections moved to IPv6, and keeping an IPv4 address became a $4 per month add-on. Supabase was open that this passed along a new AWS charge. It is also a line item that did not exist before.
  • August 2024: add-ons went hourly. IPv4, custom domains, and point-in-time recovery moved to usage-based billing prorated to the hour, at the same monthly rates.
  • Today. From supabase.com/pricing, checked 2026-10-02: the free plan is 500 MB and two active projects, paused after one week of inactivity. The paid plan is a $25 base that includes 8 GB of disk, 250 GB of egress, and 100,000 monthly active users, then $0.125 per GB, $0.09 per GB, and $0.00325 per user beyond those. Compute runs from $10 a month for the smallest instance up through sizes in the thousands. Point-in-time recovery is $100 a month per 7 days of retention. The next plan up is $599 a month.

None of those steps is outrageous on its own, and a couple of them saved some customers money. But put them in a row and the direction is clear: the price you see stays at $25, and the bill you get is the sum of a growing list of meters. A structure like that can raise what you pay without ever announcing a price increase. Lower an included allowance, resize a credit, split a feature into an add-on, and the pricing page still says $25.

What the money has to do

Here is the funding history, all from Supabase's own announcements and the coverage around them:

That is $950 million in eighteen months. I do not say that as a criticism. It is an extraordinary run and the product earned it. But a valuation in that range is a promise to investors about future revenue, and the revenue has to come from the customer base. A free tier funded by that kind of capital is generous for as long as growth is the goal. Once the goal becomes margin, the free tier and the cheapest paid plan are the least defended lines in the spreadsheet.

The other thing to notice is who the product is now being built for. In June, Supabase said more than 60% of new databases were launched by an AI tool. This week the number is 70%. The stated purpose of buying Turso is to give "every agent its own database." When most of your new databases are created by platforms on behalf of their users, your customer is the platform, and pricing and roadmap follow the customer. A person with three side projects and a credit card is not who the next eighteen months get designed around.

Neon is the precedent worth being fair about. After Databricks bought it, prices went down. Acquisitions do not automatically mean worse deals, and I would not be surprised if Turso Cloud gets cheaper for a while. The concern is not next quarter. It is what happens to the small customer once there is nobody left competing for them.

If you run libSQL

libSQL itself is safe in the way that matters. It is MIT licensed, the sqld server runs anywhere, and no acquisition can revoke that. Code written against @libsql/client takes a URL and a token and does not care who operates the server.

What changed is the stewardship. libSQL was already the older engine at Turso, with the last tagged server release in February 2025 and new features going to the Rust rewrite. Its maintainer is now joining a Postgres company whose announced plan for SQLite users is to graduate them to Postgres. I would not expect libSQL to be abandoned. I would also not plan around it receiving new investment.

Turso Cloud specifically has features nobody else matches, embedded replica sync above all. If your app depends on that, stay. If you use Turso as a plain hosted SQLite you reach over the network, your exposure is the pricing model, which meters rows read and written, and that model now belongs to a new owner with a different business.

If you run Postgres on Supabase

Nothing about your project is different today. The question is how much of your stack is portable if the terms change.

The database half is ordinary Postgres and moves with pg_dump. The rest of the bundle is the lock-in: Supabase Auth lives in a schema inside your project and cannot run without one, and storage, realtime, and edge functions are Supabase services, not Postgres features. The more of the bundle you use, the more a pricing change is something you absorb rather than something you can walk away from. That is fine as long as it is a decision you made on purpose.

Where Layerbase fits

What I build is Layerbase Cloud, and it is deliberately the boring version of all this. It runs the upstream engines, 18 of them on one account, including Postgres and libSQL. Pricing is flat: Free is $0 for 2 databases and 5 GB with no card, Solo is $5/month, and Pro is $15/month for up to 10 databases. There is no meter on rows, queries, connections, or active users, so the bill is the number on the pricing page.

Postgres and libSQL are both on the free plan. Branching works on 16 engines, both of those included.

I am not going to promise you that a company's future is fixed, mine included, because nobody can. The promise I can make is structural. Your Postgres here is stock Postgres and your libSQL is the upstream sqld, so leaving us is a dump and a connection string, the same as arriving. A host that is easy to leave has to keep earning the customer, and that is the property I would look for in any vendor right now, whether or not it is us.

You should also know what we do not have:

  • No backend bundle. We host databases. There is no hosted auth service, object storage, realtime, or edge functions. If you use and like those, Supabase is still the product for that, and Supabase alternatives goes through when to stay.
  • No embedded replicas for libSQL, and no multi-region placement. We run a primary you connect to over the network.
  • No point-in-time recovery to an arbitrary timestamp. We take backups.
  • Free databases sleep. They hibernate after 15 idle minutes and wake on connect, and archive after 14 idle days. Paid plans do not auto-archive.

What I would do this week

You do not need to migrate anything because of a press release. I would do three small things instead.

  1. Take a dump. A pg_dump of your Supabase database, or a .dump of your Turso database, stored somewhere you control. It costs minutes, and it turns a future migration from a project into a restore.
  2. List what is not portable. Write down which Supabase services or Turso features your app actually calls. That list is your real switching cost, and most people have never looked at it.
  3. Stand up a fallback. Create a free Postgres or free libSQL and restore the dump into it once, so you know the path works. If you ever want to move for real, layerbase.com/migrate/supabase and layerbase.com/migrate/turso do the copy for you, and the written guides are migrating from Supabase and migrating from Turso.

FAQ

Did Supabase buy Turso?

Supabase announced on October 2, 2026 that it is acquiring Turso. Neither company has disclosed the price or said the deal has closed. Turso's founder, Glauber Costa, joins Supabase as Head of Agentic Services.

Will Turso shut down or change its pricing?

Both companies say Turso keeps running and that nothing changes for existing users. Neither announcement makes any commitment about future pricing or plans, so treat today's Turso prices as today's prices.

What happens to libSQL?

libSQL is MIT licensed and can be run by anyone, so it cannot be taken away. It was already in maintenance mode before the acquisition, with new development going to Turso Database, the Rust rewrite. Turso's announcement commits to keeping Turso Database open source and does not mention libSQL.

Has Supabase raised its prices?

Not the headline price. The paid plan has kept a $25 base. What changed over time is the structure: billing moved to organizations with compute charged per project in 2023, IPv4 became a $4 add-on in 2024, and usage beyond the included disk, egress, and active users is metered. The bill can grow without the base price moving.

Are Supabase and Neon a monopoly?

Not on Postgres as a whole, where the large clouds are much bigger. They are the two defaults for new small projects and AI app builders, and the independent companies that competed for that position have been acquired: Neon by Databricks, Crunchy Data by Snowflake, and now Turso by Supabase. For an individual developer, fewer independent options means less pressure on anyone to keep the cheap plans cheap.

Should I move off Supabase or Turso now?

No, not because of this announcement. Take a dump, work out which platform-specific features you depend on, and test a restore somewhere else once. Then you can decide on the day the terms change, with the hard part already done.

Can I host both Postgres and libSQL on Layerbase?

Yes. Both are available on the free plan on Layerbase Cloud, on one account, at a flat monthly price with no usage meter.