I was a Fauna customer and also worked with them providing technical writing for their blog and docs. At one point I was even contacted by a publisher to write a book about Fauna.
I don't know what happened internally but when they accepted VC money and put a new CEO it all started to go down, fast. They probably started focusing on selling to corps instead of devs which seemed illogical IMO. Corps bring more money but at the time it was clear to me that Fauna would never be able to compete in with on-prem SQL-heavy kind of environments.
Fauna made sense as a secondary database for certain use cases that needed to be global... but who would use a high risk database with no fallback as their main database? Maybe small projects but definitely not big companies/products.
A decade ago it seemed that edge computing, serverless, and distributed data was the future. Fauna made a lot of sense in that vision. But in these years since, experimenting with edge stuff, I've learned that most data doesn't really need to be distributed. You don't need such a sophisticated solution to cache a subset of data for reads in a CDN or some KV. What I'm saying is that, probably, Cloudflare Workers KV and similar services killed Fauna.
you really should scale vertically until you can't anymore. a server with two 64 core epyc CPUs and 3TB of RAM and 24 NVMe flash SSDs is going to be able to handle 99% of companies SQL DB needs.
Agree. The microservice "shared nothing" NoSQL-oriented approach has, IMO, shown itself to be a cargo-cult of FAANG practices that are just not worth the downsides in practice at that 99% of companies.
It's so rare that it's barely worth mentioning. Sure, there are use cases where any rare thing might become necessary, but it's far from the default everyone assumes it to be.
I mostly agree with you, but a single server won’t solve redundancy and disaster recovery. That doesn’t mean you need to adopt a fully distributed system – a read replica or even periodic backup should be sufficient – but it’s not as simple as “just use a single server.”
Stackoverflow is famously powered by a cluster of three vertically scaled database servers.
The complexity you avoid by choosing this 'scale vertically all the way' approach is _huge_.
Like you say, deploy read replicas or automate regular backups (with regularly tested restore automation), whatever you need to meet your RTO and RPOs.
You need to be able to ignore any ignorant sales/marketing/growth management that try to tell you "we can't afford any downtime at all!!!" and have enough internal political power on the tech side. Tech leadership should be able to document the costs of each extra nine of uptime to senior management and have them acknowledge that occasional second or perhaps even minutes of downtime during failover is acceptable.
By the time you start approaching the limits of your server with two 64 core epyc CPUs and 3TB of RAM and 24 NVMe flash SSDs - hopefully you no longer need to take advice from randoms on HN because you should by then have 100+ database and network engineers working follow the sun shifts with some _really_ smart and deeply experienced dedicated database leadership managing them.
Or, you need to get someone on board to teach all your junior devs or "vibe coders" about database indexes and how to construct queries that don't do multiple fulltable scans just to render some user profile widget on every page load... "But it wrks fine on my laptop!!!" (with a whole 7 user accounts and 47 rows in the user_activity table...)
Realistically for a production database you would use a clustering technology like Oracle RAC or SQL Server Always On Failover Clustering or Always On Availability Groups
We were Fauna users for several years and invested a lot of time working with it and around it. The time travel capability was one of the stand out features for us in addition to FQL which opened some interesting capabilities. That being said for various reasons we had to transition away from it and did so by creating a FQL compatible solution on top of Postgres. It is implemented in JavaScript/TypeScript and runs in Postgres through the plv8 extension. Is this something that would be interesting to other current users?
I really think any help the community could offer - and also receive - would be welcome news for those still on Fauna service right now. Especially open source. People could move quickly – with multiple options – to help themselves, which after all is the only thing Fauna the co is able to offer anyway. Like the other commenter said, if you do release it open source please post on Hacker News and maybe Reddit and we'll all try to help boost it.
This is a very tough announcement for any customers relying on the Fauna service. The announcement itself hides the all key details, clicking into the FAQ reveals the date is not several months away but in fact 2 months 11 days away, and there is no FaunaDB open source release to start saving your own ass today.
> we have made the hard decision to sunset the Fauna service over the next several months. clicks into the FAQ
vs
> Fauna service will be ending on May 30, 2025.
Although I'm not a fauna user, I like studying databases and query languages.
I've followed them since Jepsen¹ reviewed FaunaDB 2.5.4 back in 2019.
While their FQL looks useful, I can't imagine using a SaaS-only proprietary
query language in this age for anything other than a research proof-of-concept
to learn more about my problem before building a real product on an open platform.
Curious that Bob Muglia (ex Snowflake) is on their board. I believe he's
also on the board of Relational AI which is another SaaS with an interesting
but proprietary query language. Snowflake is a huge success in spite of
being proprietary because its SQL isn't hard to learn or use, but I can't
say the same about rAI. Makes me wonder how they will turn out.
Someone told me FaunaDB the company had a strict "no one gets fired" policy. However, they also hired a few toxic people, and that created a dilemma for some folks because it was either leave or learn to tolerate toxicity.
I led the engineering team at Fauna and this is false - we had a performance culture and performance managed/exited people when they did not meet expectations. I've managed some outstanding teams/organizations at Microsoft, Amazon, and Riot Games and the team behind Fauna was world-class; on par with the best teams that I have seen or been a part of. There are plenty of reasons that the company didn't succeed, some in our control and some out of our control, but the caliber of people at the company and the company culture are not on that list.
Don't fire employees immediately when they make mistakes, sure. But not firing them at all, even if they are obviously bad for your company? That's just bad management
Definitely one of the most unpleasant jobs* of a manager is having to hold people accountable for their actions in this way, but yeah. Refusing to address it is the coward's move, and it'll destroy your culture.
* Second only to having to field questions about and spin upper management decisions that you also disagree with.
If they were making money hand over fist, they would likely just change the policy. Or at least if somebody would acquire them.
Apparently their VC investors were not seeing the hockey stick growth, so they decided to cut the losses. Taking VC money is a more risky bet than other forms of investment. If your business is profitable, but small and is growing 5-7% a year, and no acquisition is sight, most likely it's going to be shut down.
Exactly. It could have been a bootstrapped business possibly, maybe with traditional loans for business growth.
But if you take the rocket fuel of VC financing, you either accelerate so fast as to reach the orbit, or you crash back to earth. There's no glider option then.
So sad, I was looking at Fauna for a MongoDB alternative after they removed their serverless tier.
But still I'm glad I didn't go with Fauna, especially after knowing they are shutting down.
I’m only comfortable with proprietary infrastructure if I can convince myself that 1) I could get off of it if I wanted to (e.g. can I get my data back out?) and 2) the near-term gains are going to offset the work associated with getting off of it.
That is the exact opposite of the dynamic that VC funded infra companies aim for. They want you dependent and addicted, so you can be cited as part of their durable advantage/moat for their next round.
Wow! I was looking at Fauna for a new project just yesterday. The tech looks good but a custom query language put me off pretty fast. Is this a real language or just an ORM syntax? Can I push code into the DB, or is it like the HCL of SQL?
Even so, I hope it takes on a new life as an open source project and finds success. Looking forward to reading the code.
I found Fauna very interesting from a technical perspective many years ago, but even then, the idea of a fully proprietary cloud database with no reasonable migration options seemed pretty crazy at the time. I thought maybe they had some good source of very specific niche customers who fine with that, but it seems even if that was true it wasn't enough for a grow.
Really hope that something useful will be open sourced as result.
One of the services that can replace the fauna service is DocumentDB Postgres plugin (+proxy that is not open sourced yet, but will be shortly). It's available on Azure, but I can also see other Postgres Providers will start picking this up.
Such a bummer logging into the fauna dashboard this morning.. I built a lot of my product's logic around fauna and it's tied in really deeply throughout my software. Really bummed to have to rip it all out after all the work done getting it properly integrated in the first place.
I've expected this to happen, but tbh i didn't expect it to take this long.
They went for a fundamentally "lock in to a startup DB that's fully proprietary so you're screwed if we go under" which is now happening.
Open source _helps a bit_, but it doesn't change that customers now have to self-manage a database. I'm guessing most of their customers are not particularly savvy at DB self-hosting.
Yeah. It is surprising this announcement does not come with link to Github.
Hopefully they can follow through - the challenge in such situation might be relying on some proprietary technology for your SaaS which you can't open source.
Considering they only have “hundreds” of paid users despite how much money they’ve likely burned through, I’m guessing they just couldn’t raise enough additional capital to keep the lights on.
I think it's interesting that they note they have hundreds of customers but their home page says it's trusted by thousands of companies. Are all these companies on a free tier?
I would imagine it's the usual SaaS marketing embellishment, e.g. one Google employee used the software on a trial at some point === "Trusted by Google"
> they can shut down abruptly leaving you in the bind
"We understand that this is going to be a disruptive change to many and are fully committed to working with you to help you migrate off the service over the next several months."
It is 2 months to switch to a totally different database with a totally different query language. That is not easy even if you get some "help" from a company shutting down.
I honestly don't understand the path of creating a fully proprietary SaaS these days if you cannot offer a fundamentally unique capability. Speed and scalability are conveniences more than a real business moat, I suspect.
Yes. The keyword is "Proprietary" whenever it is offered by large company or small, Open Source solution you can chose to migrate to is what really offers you safety. This also tends to ensure multiple DBaaS vendors are available.
If AWS would chose to kill MySQL RDS... there are number of other solutions for MySQL DBaaS... even on AWS cloud.
Your argument would be more effective if you had linked to a source showing that Google had discontinued at least one GCP product. I count zero on that page.
(If you think "Google Cloud IoT Core" or "Google Cloud Prediction API" count, then I'm afraid you've made the opposite point you were trying to make.)
Google is the exception that proves the rule. Companies are fearful of using GCP exactly because of their terrible reputation of unreliability (and lack of even basic support).
No one fears AWS or Azure is going to shut down services they rely on (even if it happens in some rare cases).
> AWS or Azure is going to shut down services they rely on
If we give the benefit of the doubt to a quick internet search, e.g. AWS: S3 Select, CloudSearch, Cloud9, SimpleDB, Forecast, Data Pipeline, and CodeCommit.
All closed to new business, closure pending for existing customers.
I'm sure if you read the small print, neither AWS or Azure make you any promises about the longevity of their services.
Infact, if you believe in the cloud mantra, then you should treat all cloud services as a commodity that can undergo substancial changes or removal at any time.
Not knowing the facts for those specific services but I assume it's more than a 2 months period for migration:
> The Fauna service will be ending on May 30, 2025
E.g. Microsoft shut down (is still shutting down) Classic Admin Roles for Azure subscriptions for close to 9 months now.also, closed for new business also means there's no reason to migrate away if you've never got onto it - and you can still use it if you're already on it.
2.5 months to migrate off a service is way to short, especially in a time where no support from the supplier (Fauna) can be expected as employees will leave to (if they can).
Google's GCP Discontinuation of Services policy requires 1 year advance notice for generally available services; this includes any significant backwards incompatible changes.
I don't think they went against that policy for the past 16 years. I've certainly had services running there non-stop, with little to no maintenance, for about a decade.
No new customers is not shutting down services you rely on. It's the exact opposite. It's making sure things you rely on continue to work until you are ok leaving it.
And SimpleDB has been deprecated for years. I don't know think there's a single service you could have picked to better highlight the point.
AWS does close services, from time to time, all companies do, but the services they choose and the way they do it instill confidence in customers. The way GCP does it instills fear
Even mongo only got a lot of people excited because they had hot girls on the stalls in the conferences. That i think was a master stroke in marketing to nerds. of course later on they improved the product as well, but initially it was a buggy mess and should not have survived the first few years.
The one constant in my career has been mongoDB -- specifically, projects to replace it with a relational database after a deployment had failed to deliver any of the expected benefits, and introduced unforeseen downsides that had become untenable. Mongo has literally never come up in any context for me where it wasn't either already, or eventually, slated for retirement.
I absolutely don't doubt a document store including mongo is an ideal solution for certain specific applications. I just haven't come across one yet personally. For me personally, I would use Postgres for most things and JSONB columns for document-like things until I found a reason to change.
The reason to change is scale. If your Postgres spend is in the six digits a month range, JSONB is probably very painful for you. It does not perform very well. Additionally, you've probably spent a good amount of engineering time painstakingly sharding your database at the application level and hoping you've done it correctly. MongoDB solves these problems out of the box, among others. I have run both of these above 1M a month in spend and I would certainly choose MongoDB for this over Postgres. If you plan on never spending a lot on your database, I do like Postgres a lot, still.
See, that's exactly why I carefully said I'm sure it exists.
I've personally never had to shard anything in my professional career. Although IDK how painstaking the sharding would really be for most uses I can imagine besides like, social media. Facebook has to deal with everyone interacting with everyone. But the vast majority of situations most developers see isn't like that. You can run Salesforce purely sharding at the tenant level, since I only need to see my tenant's data.
Anyway I feel the need to be emphatic, I'm sure Mongo's benefits can be realized somewhere, just not in any small or medium sized company that doesn't need sharding, and does need a schema.
Everyone earns the scars from understanding that all data has a schema. If you use pg, you mostly resolve the schema on write; if you use mongodb, you resolve it into a schema on read as well. The latter turns out to be very hard to make robust.
looks like a dope product. sad they're shutting down - which means people losing jobs.
some of these things have to be open source from the get go & secure a cloud partnership.
for simple dev's like me sticking to the old and trusted relational model seems you never lose. it's always there & you're not worried about a service provider going away
It's a good idea to find out if the company you're working for is focused on growth or profit. If growth then run because it means the business model isn't profitable which means they will eventually reduce workforce and operations.
Hopefully a new company will form to pick up the open source pieces and go from there. I wonder if Fauna tried to find a buyer - it seems like they have some valuable software but weren't able to make it work. Shutting down in 2.5 months is pretty aggressive. Good luck to the former customers.
I was expecting the migration guide to recommend some other options. I don't know of other BaaS document databases like Fauna. I guess Mongo, CouchDB, Couchbase, and traditional Postgres would be the first open source options to look for. DocumentDB for closed source but offered by a big cloud vendor (AWS). If you want to roll the dice again, then maybe SurrealDB or RavenDB.
We left when their pricing shot up to $500/mo for what we thought were some basic features. That and they fought us tooth and nail to be able to make local backups of OUR data, I say good riddance.
Not super familiar with Fauna as a company... not sure "random" applies, but I generally think the same way. If a provider can offer something that adds real value over alternatives, though, it's not a bad decision to go external.
However, never rely on an external provider if there's not a low-risk offramp plan. Can I export all of my data and easily migrate, worst case scenario? Are there open source options using the same or similar formats/workflows/etc? Is the format itself proprietary or lock me in otherwise? Those sorts of questions need to be figured out fully before jumping aboard.
I don't know what happened internally but when they accepted VC money and put a new CEO it all started to go down, fast. They probably started focusing on selling to corps instead of devs which seemed illogical IMO. Corps bring more money but at the time it was clear to me that Fauna would never be able to compete in with on-prem SQL-heavy kind of environments.
Fauna made sense as a secondary database for certain use cases that needed to be global... but who would use a high risk database with no fallback as their main database? Maybe small projects but definitely not big companies/products.
A decade ago it seemed that edge computing, serverless, and distributed data was the future. Fauna made a lot of sense in that vision. But in these years since, experimenting with edge stuff, I've learned that most data doesn't really need to be distributed. You don't need such a sophisticated solution to cache a subset of data for reads in a CDN or some KV. What I'm saying is that, probably, Cloudflare Workers KV and similar services killed Fauna.