Ask HN: What are the top BaaS (Back end as a Service) platforms in 2023 | Hacker News Reader

Ask HN: What are the top BaaS (Back end as a Service) platforms in 2023

18 pointsrexarex22 comments

Hi! I am spinning up a side project and am looking into some backend as a service solutions. As a backend dev in a larger organization I have always just build stuff using AWS and rolled our own, but now I want to iterate quickly and have some stuff built in at first.

The backend engineer in me is a little wary of using these and it seems like it will be hard to get off these platforms later. Firebase looks cool, but I worry about using a NoSQL database in 2023. The AWS Amplify solution is tempting, but knowing AWS it will be clunky and require more time to administrate.

Does anyone have any suggestions or experience in using a BAAS? Thanks.

edit: I also have seen some hype on using Supabase which uses postgres, and a new firebase competitor named Convex which seems very new.

View on HN

The only truely freeing BaaS is Pocketbase. You can write your custom code in Go and deploy a single binary. Absolute control, simplest of the solutions. It is as close to pure magic and I have tried all the other bases like Supabase, Hasura, NHost etc.

Supabase developer here. We're big fans of Pocketbase here and love the stuff they're doing. I did some work with it early on and it's great, but since I'm not a Go developer, I found the customization options pretty lacking. I wish they'd develop a way to write custom code in Typescript or some other way to write custom database functions. I'm excited to see what's in store for the future of Pocketbase (as I've always been a fan of Sqlite and it's compactness and simplicity.)

Yes, but this uses SQLite as a database right?

I worked at startups (like, really really early stage Mickey Mouse ones, nothing serious) that used Firebase and Amplify. I think the toolchain for Amplify is nicer, but more dials means more mistakes can be made by juniors. Firebase's API is pretty clunky in my experience, and the docs aren't the best, but if you're building a something more in line with a CRUD app I don't think there's too much friction. That said I'd probably pick AWS because I like DynamoDB better than Firebase's Realtime DB or Firestore, and the managed backend is pretty easily understood. Maybe if analytics are important than Firebase has better integration there, but you could always just handle that externally on the app itself.

CockroachDB and Cloud Run. I absolutely would not start a new project on a database that’s not sharded by default.

Full Disclosure, I'm one of the founders of WunderGraph, but I thought I provide my 2 cents.

> The backend engineer in me is a little wary of using these and it seems like it will be hard to get off these platforms later

We're open source with a Apache-2.0 license and will never switch it.

You can also self host it yourself on your architecture or you can host it on ours.

What I like about WunderGraph personally is that it allows you to create your own firebase like toolkit with the tools you want, without getting locked into 1 vendor.

Give it a try and let me know what you think!

https://wundergraph.com/

[I work for Firebase]

One of the advantages we offer is ease of use backed up by GCP scale, reliability, and wide variety of additional products.

For example if you use Firestone and Cloud Functions with Firebase, you will still see your instances in GCP.

In that sense Amplify offers a similar experience but a higher complexity and a smaller community.

Firebase is good for getting started quickly as it provides the hosting, scaling and web and mobile apis in one place. It is proprietary though - but not too hard to move a codebase to Parse later if you needed to.

I have built an open source starter kit for web apps built on NextJS and Firebase: https://firestarterapp.com. And intend to smooth out bugs and add more features over the coming days and weeks.

I've made multiple projects with firebase, but the main problem for me was lack of SQL database. NoSQL was a bad choice literally on all of the projects I've decided to give it a try.

Hi y'all,

I'm building Singlebase.Cloud[1], the next generation BaaS, that will provide a NoSQL Datastore, Authentication, Storage, Search, Image processing, Analytics and more.

All with a friendly API to access and manipulate your data via SQL, GraphQL, REST.

Granted it's not a SQL DB, it provides a SQL interface to query and update your data.

And for GraphQL, your data becomes the schema. There is no need to build a schema, whatever you throw at it, it will return it, if it exists in the response. Making the GraphQL a presentation layer. (I think it's cool)

Let me know what you think of the idea.

[1]https://singlebase.cloud/

Supabase

The one thing I dislike about what they offer is no message queue service seems to available besides this seemingly vaporware 'workflows' feature https://supabase.com/blog/supabase-workflows

Why? What is it? What problem is it solving?

https://supabase.com/

"Supabase is an open source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, and Storage."

Budibase is interesting too.

People seem to like Appwrite as well.

I enjoy it because it introduced me to Postgres, which coming from firebase and NoSQL was refreshing

Hasura, Budibase, Supabase all were enough to finally have me spend enough time around Postgres.

I hear you on firebase/NoSQL. It's never quite made sense to me when people select non-relational databases to spend an extraordinary amount of time and effort to make it into a relational database. It's more work that just learning relational databases. I'm learning more about knowledge graphs that are not strictly programatically managed and it's been fun so far.

Vercel for Next.js and Svelte deployments. Planetscale for MySQL hosting and scaling. Supabase for Postgres and extras.

Aws Lightsail is a lightweight version of aws. I find it handy for prototypes and small builds.

i would spin up dynamo table and lambda function if you doing prototype. can you provide more requirements? not sure what all you need in backend as service

Sure. It is an MVP for a CRUD app and would have some minor async worker stuff as well. The authentication piece of some of these BaaS is compelling.

Ideally a scalable solution that supports queues and uses a relational DB for easy migration to AWS in the future should the product scale. Ideally trying to avoid getting locked into a limited platform and needing to kludge around it

Hello rexarex,

The use-case you're describing could be a great fit for the tool we're building: stacktape.com.

It offer the simplicity a productivity of a PaaS platform directly in your own AWS account. It supports all of the infrastructure components you've mentioned.

It's a tool made for developers that want to deploy their apps to AWS without having to learn all of the DevOps/Cloud/AWS knowledge.

Unlike other PaaS platforms, Stacktape deploys your apps to your own AWS account and allows you to extend/override anything, giving your the full control and minimum amount of vendor lock-in.

Supabase is amazing

Reply on news.ycombinator.com