Paul ter Laak
·7 min read
My Database Provider Got Acquired. I Had 60 Days to Migrate.
On December 2nd, 2025, I opened my inbox and felt my stomach drop.
On December 2nd, 2025, I opened my inbox and felt my stomach drop.
"Action Required: Gel Cloud is shutting down" read the subject line. The email was from Gel (formerly EdgeDB), the database I'd been building my SaaS on for over a year.
At first, I thought it was a routine maintenance notice. Maybe some scheduled downtime? Then I read the actual message.
"Effective today, Gel Cloud will no longer accept new registrations or creation of new database instances and will be fully shut down on Jan 31 of next year."
I had been running my SaaS, Virtoura, on Gel Cloud since July 2024. All my user data. All my spaces. All my subscriptions. Everything was sitting on infrastructure that would cease to exist in 60 days.
This is the story of how I rebuilt my entire backend on Convex in 7 weeks.
Let me rewind to July 2024. I was building Virtoura, a platform for creating immersive virtual tours. I needed a database, and I was tired of writing SQL.
EdgeDB (as it was called then) caught my attention with a bold promise: a database designed for developers, with a query language that actually made sense. No more JOIN gymnastics. No more N+1 queries hiding in your ORM. Just clean, composable queries.
My first commit using EdgeDB was on July 27, 2024. The learning curve was steep. EdgeQL is its own language, and the schema definition syntax took some getting used to. But once it clicked, I was hooked.
What I loved about Gel:
EdgeQL's composability. Fetching a user with their related spaces wasn't a multi-step process or a complex JOIN. It was just... natural. You described what you wanted, and EdgeQL figured out how to get it.
Declarative schema. No migration files to manage manually. You defined your schema, and Gel generated the migrations for you. Change a field type? Add a relationship? Just update the schema and run the migration tool.
Built-in authentication. This was huge. Gel came with a Next.js package that handled email/password auth, OAuth providers, and session management out of the box. No need to integrate a third-party auth service.
Access policies. Row-level security, declared right in your schema. Want to ensure users can only see their own data? One line of policy code, enforced at the database level.
I spent months building on this foundation. It felt like the future of databases.
Back to December 2nd, 2025. The Gel team's blog post was gracious about the acquisition. They were joining Vercel to help build "the best Python cloud in the world." They reflected honestly on what worked and what didn't.
But none of that mattered to me in that moment. What mattered was this:
"Gel Cloud will be fully shut down on Jan 31 of next year."
I had options. The blog post mentioned them:
For about five minutes, I considered self-hosting. Gel is open source, after all. I could spin up a Postgres instance, deploy Gel alongside it, and keep everything running.
Then I remembered why I chose Gel Cloud in the first place.
I have a strong dislike for self-hosting. I'm not a DevOps engineer. I don't want to be woken up at 3 AM because a database server ran out of disk space. I don't want to manage security patches, backups, or failover configurations.
I want to build products. I want to ship features. I want to focus on what makes my SaaS valuable to users, not on keeping infrastructure alive.
Self-hosting was off the table. That left migration.
The next few days were a blur of research. I evaluated everything:
Supabase. Postgres-based, great ecosystem, but I'd be back to writing SQL (or using their client libraries). The real-time features were appealing, but I'd lose the query composability I loved.
PlanetScale. MySQL-based, serverless, great DX. But again, back to SQL. And I'd need to figure out auth separately.
Neon. Serverless Postgres, promising architecture. But same story: SQL and separate auth.
Turso. SQLite at the edge, interesting approach. But I wasn't sure about the maturity for a production SaaS.
Then I stumbled across Convex.
Convex is different. It's not trying to be a better SQL database. It's rethinking what a backend should be.
Here's what caught my attention:
Real-time by default. Every query in Convex is a subscription. When data changes, your UI updates automatically. No WebSocket configuration. No polling. Just reactive data.
TypeScript end-to-end. Your schema is TypeScript. Your queries are TypeScript. Your mutations are TypeScript. Full type safety from database to UI, with inference that actually works.
No connection pooling. This might sound minor, but if you've ever dealt with "too many connections" errors in a serverless environment, you know the pain. Convex handles all of that.
Functions, not just data. Convex isn't just a database. It's a backend platform. Queries, mutations, actions, scheduled jobs, all in one place. No need for a separate API layer.
Convex helpers ecosystem. The community has built incredible tooling around Convex. Relationship helpers, validation utilities, even auth adapters.
I read the docs. I built a hello world. I joined the Discord.
Within a day, I knew Convex was the answer.
Here's what I was facing:
Schema transformation. Gel allowed nested objects in your schema. Convex requires flat tables with explicit relationships. My entire data model needed restructuring.
40+ server actions. Every query, every mutation, every API call to external services needed to be rewritten.
Authentication. Gel's built-in auth wouldn't transfer. I needed a new solution that could preserve my users' ability to log in without resetting passwords.
Data migration. Thousands of records needed to be exported from Gel and imported into Convex, with all relationships intact.
Production deployment. This wasn't a side project. Real users depended on this working.
I had 7 weeks until Gel Cloud shut down. The clock was ticking.
Somewhere in the first week, I decided to document the entire migration. Not just for future me, but for anyone else who might face a similar situation.
Because here's the thing: forced migrations suck. But they also force you to question decisions you've been taking for granted. They make you evaluate the entire landscape again with fresh eyes.
And sometimes, you end up somewhere better than where you started.
This is the first post in a 12-part series documenting my migration from Gel to Convex. Over the next six weeks, I'll cover:
The migration was one of the most intense development experiences of my career. It was stressful, educational, and ultimately rewarding.
If you're building on any third-party infrastructure, this series is for you. Not because you should be paranoid about your vendors, but because understanding how to migrate is part of understanding how to build.
Let's dive in.