Fauna has shut down: migrating off it, and what to use instead

Fauna announced in March 2025 that it was winding down its hosted database service, with the service ending on 30 May 2025. The company said it had been unable to raise the capital needed to continue, and committed to releasing an open-source version of the core database technology.

So a page about connecting an automation to Fauna would be describing something that no longer exists. What is genuinely useful is the other thing: if you are still carrying a Fauna dependency, how to get off it, and how to choose a replacement without walking into the same position again.

What we'll cover

• What actually happened
• If you are still on it
• Getting the data out
• The hard part: FQL does not translate
• Choosing the replacement
• Connecting the new database to CodeWords
• Running the migration without downtime
• Reconciliation, the part worth automating
• Avoiding the same position next time
• What to do first
• Frequently asked questions

What actually happened

The service was sunset on 30 May 2025, announced in March of that year.

The stated reason was capital. The company said the board and investors concluded the funding required to continue independently was not available.

Migration support was offered to customers on paid plans, with community support for free and pay-as-you-go users.

An open-source release of the core technology was promised, so the document-relational model and FQL would remain available to the community in some form.

Reported scale of the impact was in the region of hundreds of databases and thousands of development teams.

If you are reading this because a service you inherited still references Fauna, the situation is that the hosted database is gone and whatever depended on it has either been migrated or has stopped working.

If you are still on it

Unlikely at this distance, and not impossible — dormant projects, archived services, and internal tools outlive the attention paid to them.

Find the dependencies first. Search your codebases for the client libraries and for connection secrets, since the references are usually more numerous than anybody remembers.

Check what is actually running. A service with a Fauna dependency that has been failing quietly for months is a different problem from one still serving traffic.

Look for the data, not just the code. If a backup or export was taken at the time, it is the thing you need, and it is typically in somebody's cloud storage rather than anywhere obvious.

Treat it as a data recovery exercise rather than a migration if the service is already gone, and set expectations accordingly.

Getting the data out

If you hold an export, or are migrating a system that was exported at the time, the shape of the work is consistent.

Documents come out as JSON, with Fauna's own reference and metadata fields alongside your application data.

References need translating. Fauna's document references are not foreign keys, and every one becomes a decision about how the relationship is represented in the target.

Timestamps and temporality. Fauna's versioning meant a document had history; most targets do not, so decide whether you need the history or only the current state.

Collections map to tables or collections in the target, which is the straightforward part.

Indexes do not map at all, since Fauna's index model is specific to it. Plan to design the target's indexes from your query patterns rather than translating.

The hard part: FQL does not translate

The data is the easy half. The queries are not.

FQL is a functional query language with a model of its own, and there is no mechanical translation into SQL or into another document store's query language.

Business logic lived in queries. Fauna encouraged expressing logic in FQL, which means some of your application's behaviour is in the database layer and has to be reimplemented somewhere.

User-defined functions have to be rewritten into application code or into the target's equivalent.

Transactional guarantees differ. Fauna's consistency model was a selling point, and a target with different semantics may need application changes to preserve correctness.

Budget for this properly. Teams consistently underestimate it because the data export goes well and gives a false sense of how much is left.

Choosing the replacement

Pick by how your application actually queries, not by architecture preference.

Postgres suits most things. Relational, well understood, available from many providers, and it handles JSON well enough that a document-shaped application usually fits. The default answer unless something specific rules it out.

A document store suits genuinely document-shaped data with flexible schemas and nested structures you query as units.

A key-value store with known access patterns suits high-scale, well-understood workloads.

Serverless matters if the workload is intermittent. Scale-to-zero was part of Fauna's appeal, and it is available elsewhere now.

Weigh provider risk. That is the whole lesson here. A database available from several providers, or one you could run yourself, carries less risk than one available from exactly one company.

Connecting the new database to CodeWords

Once the replacement is chosen, the automation around it is ordinary work. CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what to read, when, and what to do with it.
3. Authorize the connection with credentials scoped to the specific database and tables.
4. Describe the exceptions: a record that failed to migrate, a reference pointing at nothing, a figure outside a plausible range.
5. Run the reconciliation described below before trusting anything.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Running the migration without downtime

If there is still a live system to move, the standard approach applies.

Write to both for a period. The application writes to the old and the new store while you verify, which is the safest route and the most work.

Backfill historical data in paced batches, keyed so the job can resume rather than restart.

Reconcile continuously. Counts, sampled contents, and spot checks of the awkward records, reported as a difference rather than resolved silently.

Switch reads before switching writes, so you find problems while the old store is still authoritative.

Keep the old data readable for longer than feels necessary, since the question you cannot answer always arrives after you deleted it.

Automate the reconciliation. It runs many times over a migration's life, and running it by hand means it runs three times and then stops.

Reconciliation, the part worth automating

Whatever the target, the migration is only finished when you can demonstrate the data arrived intact, and demonstrating that is repetitive work.

Compare counts per collection, which catches whole categories that failed to move.

Sample and compare contents, weighted towards the records most likely to be awkward — the oldest, the largest, the ones with unusual shapes.

Check references resolve. Every translated relationship is a chance to have pointed at nothing, and a dangling reference is invisible until somebody's page fails to load.

Compare aggregates that matter commercially — totals, balances, counts per customer — since those are the numbers somebody will notice being wrong.

Report the difference rather than fixing it. An automated repair during a migration hides the bug that caused the difference.

Run it on a schedule through the dual-write period, not once at the end, so a divergence is caught the day it starts rather than the week you cut over.

Avoiding the same position next time

The reasonable lesson, without being preachy about it.

Prefer databases with more than one provider. Postgres and MySQL can be moved between vendors; a proprietary database from one company cannot.

Keep business logic in your application where you control it, rather than in database-specific functions and queries.

Export regularly, and check the export restores. An export nobody has tested is a file, not a backup.

Keep the data model portable where you can. Exotic features tie you to a vendor in proportion to how much you use them.

Watch your vendors. A funding announcement, an acquisition, or a pivot is worth noticing before a shutdown notice arrives with sixty days on it.

None of this means never using a specialist database. It means knowing which of your dependencies you could actually move, and roughly what moving would cost, before you need the answer urgently.

What to do first

Find out whether you still have a dependency at all: search your repositories for Fauna client libraries and for stored credentials, and check whether anything referencing them is still deployed. Most organisations reading this will find either nothing or a dormant service nobody has thought about in a year.

Two habits make the difference. Search for the credentials as well as the code, since a secret in a configuration store is often the last surviving trace. And if you find an export, restore it somewhere and confirm it is complete — an untested export has a way of being less than it appeared.

Frequently asked questions

Is Fauna still available?

The hosted service was sunset on 30 May 2025. The company committed to an open-source release of the core technology, so the database model and FQL may be available to run yourself, but the managed service people integrated with no longer exists.

What should I migrate to?

Postgres, for most applications, unless something specific rules it out — it is well understood, available from many providers, and handles document-shaped data adequately. Choose by your actual query patterns rather than by architectural preference.

What is the hardest part of migrating?

Rewriting the queries. FQL has no mechanical translation to SQL, and applications built on Fauna often kept business logic in the database layer. The data export is straightforward and misleads teams about how much work remains.

How do I move without downtime?

Write to both stores, backfill in paced batches, reconcile continuously, then switch reads before switching writes. It is more work than a cutover and it is how you find the problems while the old store is still authoritative.

Do I need the version history?

Usually not, and decide deliberately. Fauna's temporality meant documents had history that most targets do not preserve, so if anything in your application depends on it, that needs a design decision rather than an assumption.

How do I avoid this happening again?

Prefer databases available from more than one provider, keep business logic in your application rather than in database-specific queries, and test that your exports actually restore. Then you know what moving would cost before you have to do it in sixty days.

Can CodeWords automate the migration?

It can automate the mechanical parts — batched backfills, reconciliation runs, reporting on what did not match. The query rewriting is engineering work, and anybody telling you otherwise has not looked at an FQL codebase.

How do I know the migration was complete?

Automated reconciliation: counts per collection, sampled content comparison weighted towards awkward records, reference checks, and the aggregates somebody would notice being wrong. Run it repeatedly through the dual-write period rather than once at the end.

Should reconciliation fix what it finds?

No. Report the difference. An automated repair hides whatever caused the divergence, and during a migration the cause is the thing you most need to know about.

Related reading

• PostgreSQL and CodeWords
• MongoDB and CodeWords
• CodeWords integrations and templates