Supabase alternatives: Competitors to consider in 2024

Supabase’s own website describes the product as an open source Firebase alternative –  while that’s a handy shorthand, it doesn’t reveal much of the detail. Here’s a quick run-down of what Supabase offers.

• Postgres database: At the heart of any Supabase project is a Postgres database. This makes it easy to migrate from other Postgres hosts but does limit Supabase’s functionality if another form of data storage, such as a document database, would be better suited.

• Auth: Based on Netlify’s GoTrue project, Supabase’s user authentication relies on OAuth2 and JWT to manage users and account privileges.

• Serverless functions: Otherwise known as edge functions, Supabase lets you run standalone Typescript code within the platform, meaning they can access data in Postgres and make use of other Supabase functionality, such as authentication.

• File storage: Similar to Amazon’s S3, Supabase provides object storage for media and other files used in your app.

• Realtime data synchronization: Basic WebSocket functionality, allowing for pushing data between clients and the Supabase backend.

• Vector search: Suitable for AI-type workloads, Supabase allows you to make vector searches within your Postgres data and also to integrate with LLMs such as OpenAI.

• UI: In the hosted version only, Supabase offers a web interface to edit database tables, view stored files, and more.

That’s what Supabase does. But is it suitable for your project? Let’s take a look at the pros and cons.

• Fast time to market: Outsourcing your backend to Supabase frees your team to focus on your app’s frontend and unique functionality, meaning you can deliver a working product and any updates faster than if you were using a custom backend. Features such as auto-generated CRUD APIs also reduce the amount of plumbing you need to create by hand.

• Everything you need to get started: Supabase gives you pretty much all the backend functionality you need to get your app to market. That saves you time in choosing and integrating different tooling but does mean you need to be happy that Supabase’s strategy and implementation align with your app’s long term needs.

• Built on open source technologies: As it brings together well known tech, such as Postgres, it’s relatively easy to find other tools that work with Supabase. And with most of Supabase’s original code being open source, you might be able to host your own instance, reducing the risk of vendor lock-in.

• Fast pace of product updates: Supabase has gained a reputation for shipping new functionality quickly. So far, the product has kept up with new trends such as vector search.

• Hosted and open source options: You can pay Supabase to provide you with a hosted BaaS using their global edge network or, if you want to get your hands dirty, install and run the open source parts of Supabase on your own infrastructure.

• Supabase is still in beta: As of July 2023, Supabase was still a beta product. Typically, beta software has lower reliability and is more likely to introduce breaking changes in updates than production software. Consider whether you want to take the risk of introducing a moving target into your infrastructure.

• Questions about developer experience quality: As a beta product, it appears that Supabase doesn’t have the best documentation or overall developer experience. Documentation quality can have a huge influence on developer productivity, so bear that in mind if time to market is particularly important for your product.

• Dashboard not available in the open source version: Supabase is described as open source but not everything available in the hosted version is included in the open source version. In particular, it does not include the dashboard from which you can manage the database, files, and more.

• Realtime updates are not guaranteed: Supabase does not guarantee that updates sent through WebSocket will reach their destination. That means you’ll need to create and maintain additional application logic to queue messages, track their delivery status, and resend if necessary. 

• You are tied to Supabase’s technology choices: When you choose Supabase, you outsource your technology choices to their team. That can be a benefit but if their current tech stack and future roadmap differ from your needs then you might need to look at alternatives.

• Self-hosting can be hard: Although the Supabase team is working to improve this, it can be hard to self-host Supabase due to sparse documentation. 

• Steep jump in pricing: If you choose the hosted version of Supabase then you’ll need to select a pricing tier that meets your needs. While it’s free to get started, there’s a big jump when you need production-ready functionality and quotas. For example, Supabase’s “Team” plan is more than 20 times more expensive than the entry level plan.

There’s a lot of discussion about Supabase but it might be that, once you dig a little deeper, you find it isn’t quite right for your development project. If that’s the case, what should you make sure to consider when looking at Supabase alternatives?

• Do you want the next big thing or a mature platform? For the majority of development projects, proven technology is a better choice than something that is still in development. Benefits of a mature platform include stability, greater choice of integrations, and more engineers with experience in that tech.

• Is a monolithic BaaS even the right choice? Choosing a BaaS means putting your faith in one vendor. You need to be certain that their technology choices and engineering expertise are a match for your product. There is an alternative. You can still accelerate your time to market by integrating with PaaS providers and selecting different providers for each aspect of your backend. Select from different vendors to choose a hosted database service, an auth service, and a realtime PaaS in order to stay flexible.

• Will it scale? Once you’ve selected a backend provider, it takes time and engineering effort to migrate elsewhere. Make sure the vendor you select can meet your app’s scaling needs. Ask how well their architecture and infrastructure can handle sudden, as well as planned, spikes in demand.

• What is the interface? Will your engineering team need to learn new technology to work with the provider? GraphQL, for example, is increasingly widespread but isn’t as familiar as a REST interface.

• Does it integrate with your existing tooling? Your backend doesn’t exist in isolation. What does the ecosystem of integrations look like for the tools you’re considering? Are there off the shelf options or will you need to roll your own.

• Is the developer experience up to scratch? If the documentation, SDKs, or other aspects of the developer experience are lacking then that could negate any potential productivity gains elsewhere.

• What’s the data residency and governance story? Depending on your use case and local laws, certain parts of your data might need to be resident in one particular geographic area. Similarly, ask vendors whether they support HIPAA, SOC2, and other compliance standards.

If it seems that Supabase isn’t a great fit for your application’s backend, what are your options? Other than creating your own backend from scratch, there are two main approaches:

• Find a direct Supabase alternative.

• Build a Supabase alternative by combining different services.

Google’s Firebase is the inspiration for Supabase. Launched in 2012, it aimed to provide everything developers need for the back-end of their apps. Today, Firebase offers a proprietary platform that includes a NoSQL document database, limited realtime functionality, auth, serverless functions, and more.

• Broad range of functionality: Firebase offers functionality to help you build, release, run, and market your app. Sub-products include machine learning tooling, feature flags, abuse protection, static front-end hosting, analytics, A/B testing, and more.

• Backed by Google: When you choose a BaaS, you need to be sure it’s going to be around for the lifetime of your application. Firebase is owned by Google, meaning that it has substantial financial backing. However, Google does have a reputation for closing successful products.

• Large developer community: With many developers already using Firebase, there’s a wealth of unofficial help material available in forums such as Stack Overflow and Reddit

• Vendor lock-in: Firebase is proprietary software owned and operated by Google. Once you choose Firebase there is no alternative vendor who can offer a drop-in replacement. Migrating away from Firebase would take substantial engineering effort.

• No self-hosting: Similarly, as Firebase is not open source, there’s no option to host it on your own infrastructure.

• Inflexible query: Firebase’s main database, Firestore, is a NoSQL document store, similar to MongoDB. That can be useful for some types of data but can also make it harder and slower to run complex queries.

• Limited scaling: There are several ways in which Firebase might limit your app’s scalability. Firestore can support a maximum of 1,000,000 concurrent connections and 10,000 writes per seconds. While it’s possible to increase those limits, performance will suffer. Similarly, Firebase’s Realtime Database can support only 200,000 concurrent connections.

• Limited reliability and availability: Firebase’s Realtime Database is single region. In other words, if that region goes offline then there’s no fallback. That also impacts user experience. Without a global edge network, even when there’s no downtime, data will take noticeably longer to reach end users when they are further away from the data center.

• Limited realtime functionality: For message delivery guarantees, you’ll need to use a third-party realtime PaaS instead of the Firebase Realtime Database. 

• Usage limits: Firebase is beginning to show its age. The Firestore database puts a limit of 1 MB on individual documents and each API request is limited to 10 MB

• Integrations favor the Google ecosystem: As a Google product, Firebase favors the Google ecosystem. That’s fine if you are already committed to the Google Cloud Platform but might be less convenient if you already rely on tooling that isn’t supported by Firebase.

Not long after the launch of Firebase, a company named Parse launched a similar backend as a service product. Some years later, Facebook bought Parse only to open source it and then shutter the hosted service. Back4App picks up where the hosted Parse service left off, providing a backend as a service built on top of the open source Parse. How does it compare to Supabase?

• Based on open source software: With the open source Parse at its core, there’s less risk of vendor lock-in with Back4App. If you can host Parse yourself, or use another hosted Parse service, then you’ll need to put some engineering effort into recreating any of Back4App’s proprietary functionality used by your app.

• SDK, GraphQL, and REST interfaces: Back4App offers choice in how you query your data.

• Serverless functions: Back4App supports running standalone JavaScript functions, which it calls “Cloud Code”.

• Not fully open source: Although Back4App uses the Parse open source project, it is not itself open source. That means that if you choose it and then move away to the open source Parse, you’ll need a plan for replacing Back4App’s proprietary aspects.

• Database is MongoDB: Back4App’s main database is MongoDB, although it does have some support for relational-style queries.

• Limited realtime functionality: Clients can subscribe to receive realtime updates of events in the Back4App database, using Parse’s WebSocket-based LiveQuery protocol. That’s fine for simple realtime use cases, such as broadcasting an in-game message to all players, but there’s no built-in way to queue messages for offline clients and messages are not guaranteed to arrive in order or exactly-once.

• Limited scaling: The Back4App engineering team boasts that they’ve scaled to more than 10,000 requests per second. For many use cases, that represents a low number of concurrent connections and could seriously limit your ability to scale your application.

Founded in 2019 as a response to Firebase, Nhost shares a great deal in common with Supabase. Broadly speaking, Nhost and Supabase differ mostly in the details of how each solution implements things.

• Postgres is at the heart of Nhost: Just like Supabase, each project in Nhost centers on a Postgres database, meaning you can take advantage of existing tooling and skills within your team.

• Run backend code in Nhost: Nhost supports serverless Typescript and JavaScript functions but goes a step further and allows you to run ongoing code using your preferred language, too. It even allows you to run services such as Redis and MongoDB within the Nhost infrastructure.

• Open source: Nhost is open source, meaning you should be able to avoid vendor lock-in by running your own instance

• Unproven: Nhost has a smaller developer community and is a relatively new product. That means that there are fewer developers familiar with it and less third-party support material available.

• Nhost favors GraphQL: Nhost automatically generates a GraphQL schema based on your Postgres database. That could be an advantage if GraphQL suits your needs but it isn’t as widely understood by developers as REST.

• Unclear pricing: Nhost’s Pro plan offers a good set of functionality and quotas to get started but, once you outgrow that, you’ll need to negotiate directly with the Nhost sales team as pricing for higher tiers is not published.

Choosing a backend as a service provider can help you get to market faster and save you some ongoing maintenance effort. However, it comes at the price of:

• Reduced flexibility over technology choices.

• Limited ability to scale a monolithic backend.

• Potential vendor lock-in.

• Questions about data residence and governance.

Taking a modular approach, where you mix and match between technologies from different PaaS providers helps you retain control without having to build everything from scratch. That way you can still get to market faster, and reduce your maintenance costs, while selecting the best solution for your specific needs.

As realtime is our speciality at Ably, let’s run through some of the options you have as alternatives to Supabase’s realtime functionality.

Socket.IO is an open source realtime communication library built on top of WebSocket. It aims to address some of the weaknesses in WebSocket, such as enabling automatic reconnects and falling back to HTTP long polling should WebSocket be unavailable.

• Improved efficiency: WebSocket is already an efficient way to handle realtime communication. Socket.IO builds on that by using namespaces to bundle more traffic into a single connection.

• Broadcast messages: Socket.IO enables you to send events to all connected clients. Additionally, you can target a specific group of clients using “rooms”

• Automatic reconnects: Through a configurable ping/pong heartbeat mechanism, the protocol detects broken connections and can re-establish them.

• Limited delivery guarantees: If you need to ensure a message is delivered exactly-once, you’ll need to build additional application logic to take care of that.

• Single region: By default, Socket.IO can’t handle multi-region deployments. That could expose your application to greater downtime risk.

• No built-in encryption: Overall, Socket.IO’s security story is lacking. Not only is there no support for end to end encryption but there’s no way to generate and renew auth tokens.

SignalR is a .NET library built on top of WebSocket and RPC. It’s available both as an open source project and a hosted service in Azure.

• Falls back to older technologies: Like SocketIO, SignalR will use HTTP long polling or Server Sent Events if WebSocket is unavailable.

• Supports multiple backplanes: SignalR can integrate with service buses such as Azure Service Bus, Redis, and SQL Server to help scaling.

• Broadcast messages: Like SocketIO, SignalR can broadcast messages to groups of clients for efficient delivery.

• Best suited to .NET projects: With limited support for SDKs and integrations outside the .NET ecosystem, SignalR might be the best choice if you’re primarily using other languages and frameworks.

• Single region: Like SocketIO, SignalR is designed to work in a single region, which can have an impact on your ability to withstand outages.

• Weak guarantees: SignalR offers no guarantees that your messages will be delivered. You can work around that by adding it to your application layer but that increases the complexity of your initial development and ongoing maintenance.

PubNub is a realtime PaaS built on top of HTTP long polling, which is an older predecessor to WebSocket, and built around the Publish/Subscribe (Pub/Sub) model. As a hosted service, using PubNub takes away the burden of building and operating your own infrastructure.

• Global infrastructure: PubNub’s 15 locations globally should mean clients have a reasonably low latency experience even if they’re in a less populous region.

• Integrates with many languages and frameworks: SDKs for languages such as JavaScript, PHP, Swift, Dart, and more mean PubNub is easier to integrate with your existing tooling.

• Reliability guarantees: PubNub promises 99.999% uptime.

• Quality of service is limited: PubNub won’t guarantee that your messages arrive in the right order or at all. Instead, you’ll need to build and maintain that functionality in-house.

• Interruptions in service might lead to message loss: PubNub queues only 100 messages. So, if a connection between client and server is lost, you’ll need to write your own logic to recover fully as you can’t be sure that PubNub hasn’t dropped messages.

• Complex pricing: It’s not straightforward to estimate what using PubNub might cost. Monthly pricing is based on the number of monthly active users plus how many transactions you’ve used. The complexity comes from the large number of different types of transaction, each with its own pricing criteria.

Like PubNub, Pusher is a realtime platform as a service provider. Unlike PubNub, though, Pusher uses the more reliable and efficient WebSocket protocol and will fall back to other technologies if appropriate.

• Not limited to Pub/Sub: Pusher supports Pub/Sub, one-to-one, one-to-many (fan-out), and many-to-many messaging, offering greater flexibility than some other options.

• Integrates with many languages and frameworks: Like PubNub, Pusher offers several SDKs so that you can integrate easily with languages and frameworks such as Java, Go, NodeJS, iOS, and Android.

• Some additional features: Pusher supports end to end encryption and webhooks for triggering third party tools.

• Must choose a single data center location: Although Pusher has multiple data center locations, you must choose only one for your app. That reduces reliability and increases latency.

• Weak QoS: Pusher shares one of PubNub’s weaknesses in that it doesn’t guarantee that your messages will ever reach their destination.

• Focuses on the basics: Pusher doesn’t offer much in the way of ancillary services. Instead, it acts purely as a way to get messages from one place to another. So, if you need features such as message history or integrations with tools such as Apache Kafka then you might need to choose a different provider.

Ably is a realtime PaaS that delivers low latency, guaranteed message delivery at scale across the globe. Built on top of WebSocket, and compatible with other protocols, Ably gives you the tooling and infrastructure to create slick realtime experiences such as collaborative experiences, realtime chat, data synchronization, and more. Here’s what you get when you build with Ably:

• Strong guarantees: Ably delivers 100% of messages in order, even when there’s an outage caused by issues such as network and/or hardware failures. The global Ably service ensures that no messages or data is lost.

• Global edge network: Ably achieve sub-65 ms latencies through a global network of datacenters and edge acceleration points of presence, meaning your end users experience minimal lag wherever they are.

• Excellent developer experience: Ably provides more than 25 SDKs so your engineering team can become quickly productive. Integrations with other tooling, such as Apache Kafka, mean that Ably slots neatly into your existing tech stack.

• Limitless scalability: With a 99.999% SLA and an architecture built for horizontal scaling, Ably will handle whatever peaks and troughs in demand your application experiences.

Start building with Ably

Try Ably for yourself to see just how easy and fast it is to get your realtime infrastructure up and running. Start with a free developer account today.