Supabase versus Magic - You win!

Supabase is an open source Firebase alternative. Their slogan is "build in a weekend, scale to millions". Magic is a low-code and no-code software development automation framework, intended to automate software development. Its slogan is "where the machine creates the code". Supabase has 68,000 Stargazers on GitHub. When I made Magic closed source 6 months ago it had 900 Stargazers.

Supabase value proposition

Supabase was started as a thin deployment layer on top of PostgreSQL and PostgREST, which implies that understanding Supabase requires understanding PostgREST and PostgreSQL.

PostgreSQL (often referred to as PgSQL) is one of the largest and most popular open source relational database managements systems in the world. PostgREST is a standalone web server, allowing you to turn your PostgreSQL database into a web API.

By building Supabase on top of PostgreSQL and PostgREST, developers can rapidly create a database using Supabase, for then to access this database using HTTP API endpoints, allowing them to parametrise invocations towards PostgREST that would somehow retrieve data from PostgreSQL according to whatever URL was submitted.

PostgREST also allows for updating, creating, and deleting records in its associated database, making it ipso facto a thin CRUD layer on top of PostgreSQL - With some security features, such as the ability to secure access using JWT.

Later additions to Supabase has been GraphQL (I think), in addition to implementing the vector plugin for PgSQL, allowing users to use Supabase for things typically associated with AI and machine learning projects.

No valuable IP

The first problem about Supabase is that they've got practically no valuable IP what so ever. You can deploy PgSQL and PostgREST in a DigitalOcean (DO) droplet in some few minutes. Such a droplet would cost you $6, and you'd end up with a solution without lockins, allowing you to move your solution to other VPS providers if needed in the future.

In fact, any senior software developer could probably create a Kubernetes YAML file, wrapping the entirety of Supabase's initial value proposition in a weekend, at which point your scaling features would be equal to those of Supabase. I wouldn't be surprised if DO even have pre-defined templates and wizards for deploying both PostgREST and PgSQL in a similar configuration, reducing Supabases's entire value proposition down to a couple of checkboxes at DigitalOcean.

The same argument can be applied for their vector features and GraphQL, as in there's no real IP in there that somehow makes Supabase unique in anyways. Basically ...

Any senior dev could easily replace their entire value proposition in a weekend

However, no sane senior dev would want to, because wrapping your database into CRUD endpoints is a stupid idea, unless you can somehow allow for these endpoints to also implement business logic.

It's a super dumb idea

In .Net we've had OData for more than a decade. Few serious developers gives it much attention, and it's got only 675 Stargazers on GitHub, because it's a ridiculous idea, only useful for smaller projects, and (maybe) for generating reports and such.

However, OData is basically a better version of PostgREST, and it's portable to multiple different database systems, implying you can use it for both MySQL, PgSQL, MS SQL, and any other database management systems out there. OData is even ISO standardised, making it arguably a much more "change resilient" project than PostgREST.

However, OData has got 60% of the likes that Magic has, because it's simply a dumb idea, similarly to how PostgREST is also a dumb idea.

Why it's a dumb idea

The reasons for it being a dumb idea is because even though CRUD is 80% of the problem related to building an app, if all you've got is CRUD, you will never be able to finish your app. All apps need custom business logic, besides the ability to persist data. Supabase's only solution here is something they call "edge functions", which is basically an additional process on top of PostgREST, doubling latency, and doubling the attack surface of your app.

When latency is doubled, scalability is reduced by 4. To understand the problem let's see how a typical Supabase invocation looks like.

Client invokes edge function
Edge function contains business logic
Edge function invokes PostgREST
PostgREST invokes PostgreSQL

Congratulations, you've now taken what typically should be one HTTP invocation, and you've turned it into 3 network invocations, tripling your latency, and reducing your scalability by 16 - Resulting in hardware and bandwidth requirements literally exploding to be able to simply run your app.

All of this because you didn't want to learn SQL - Resulting in that you now have to learn PostgREST, which inevitably at some point will become equally complex as SQL, if they're to be able to deliver what SQL already delivers ...

In addition users still have to create good old fashion code in these edge functions, so there are no simplicity reasons for the above architecture. The only reasons why it's applied at all in the first place, is because junior devs starts out with Supabase, believing in the marketing rubbish from Supabase, allowing them to "build apps without coding", wrapping an HTTP REST API around their database, not realising that not only do they still have to code - But they've now added multiple additional failure points and network invocations between their data and the client.

Supabase's architectural flaws are so huge that the only worse idea we've collectively had in the software development community are regular expressions

Supabase is the McDonalds of software development. Sure, you can get something into your stomach in 5 minutes, but you'll pay the price for it for the rest of your life in the form of deteriorating health.

I suspect the only reason why devs are using Supabase at all, is because junior devs sees it as an "opt out" from having to build complex backend business logic, allowing them to rapidly hammer out a simple CRUD API, for then to start implementing their React frontend.

The result of the above decision becomes that all business logic initially ends up being implementing in frontend code, resulting in "security issues" so large, that the only (real) means to actually salvage your project once you understand what you've actually done - Is to simply "SHIFT+DELETE refactor" your entire project, and start out from scratch.

And before you start reaching for GraphQL, realise it's got the exact same problem!

At this point of course, you've spent a year managing your existing codebase, while accumulating such huge amounts of technical debt, that no (sane) business owner is ever going to allow you to start over again - Thinking it'll require the same costs to start over again as it took to initially create the frikkin' spaghetti.

So you're stuck with your existing solution, desperately trying to "port" your business logic from React to NodeJS, or any of the other 100+ retarded programming languages Supabase supports in their "edge functions".

Yes, they're all retarded programming languages - But that's another article ...

Magic's value proposition

Magic is built on Hyperlambda. Hyperlambda is a functional meta programming language with declarative constructs, with AI and software development automation workflows horizontally integrated throughout the entire platform.

This allows Magic to generate HTTP CRUD API endpoints. The difference between Hyperlambda and PostgREST is that with Hyperlambda you actually end up with individual code files for each individual endpoint.

This allows you to modify these endpoint files, to add any amount of business logic you want into these CRUD endpoints - Which again removes an entire horizontal layer in your architecture, gets rid of several additional network hops, reduces latency, and completely eliminates the need for "edge functions" - And it could be argued that Hyperlambda is in fact an "edge function", with the difference being it doesn't need any "database wrapper layers", such as OData or PostgREST to access your database - And it supports MySQL in addition to PostgreSQL and Microsoft SQL Server - Plus of course SQLite, because "why not" ...?

Hyperlambda's "edge functions" and its database access layer is one thing, so they both run in the same process, and there are no additional network connections required besides the one originating from the client.

Lately we've also added the ability to use no-code and low-code constructs to declaratively add functionality into Hyperlambda files, without even having to manually create any code at all. You can see an example of the latter here.

Why Hyperlambda?

First of all, realise the only (real) alternative that exists to Hyperlambda is XML, JSON, and YAML - And XML is retarded because (duh!) it's retarded, end of debate! If I need to explain to you why XML is retarded, I suggest you read a book - ANY book will suffice ...

JSON explodes the size of your "code files" in comparison to Hyperlambda because it's a key/value format, where Hyperlambda is a name/value/children format - Allowing me to describe with 5 lines of Hyperlambda what would require 25 lines of JSON to describe. You can see the difference here if you're interested.

YAML is simply a different syntax for JSON, so it suffers from the same problems JSON suffers from, albeit resulting in slightly less verbose code than JSON - But still code easily one order of magnitude larger than its Hyperlambda equivalent.

So there are no (real) alternatives to Hyperlambda, which can be understood by seeing how 100% of every single "software development automation orchestration platform out there" is built upon either JSON or XML. The problem simply cannot be solved without something equivalent to XML, JSON, or Hyperlambda.

So in the end, even though Hyperlambda is often referred to as "a programming language", it's actually not! But rather a software development automation and orchestration markup language, that just so happens to be Turing complete, giving you constructs such as [for-each] and [if].

Magic, the cure for Supabase

I created Hyperlambda and Magic specifically to allow for refactoring idiocy-based apps, implemented on top of ridiculous architectural decisions, such as those proposed by Supabase. The idea was that as a senior dev with 42 years of experience, I was tired of maintaining rubbish code, created because of some inexperienced junior dev, having fallen for some marketing rubbish, created by some retarded company such as Supabase, with the intention of cashing in a couple of billions in VC funding, without having the audacity to hiring anyone who actually knew what they were doing.

Magic's entire purpose was to provide an "opt out" of previously applied bad architectural ideas, such as those resulting from Supabase and similar frameworks.

Initially I licensed Magic under the terms of MIT. However, after having been bullied out of Reddit, and experiencing psycho marketing managers living in Silicon Valley, refusing to allow for brilliant ideas to prevail instead of idiocy-based architectures - I simply gave up ...

Magic is closed source

About 6 months ago I stopped caring, and realised that even if I somehow at some point "won the argument" - The only thing I'd achieve, was for some idiot company such as Supabase "stealing" my open source IP, and wrapping it inside "a beautiful React wizard", plaster some marketing rubbish on top of it, for then to cash in - While I'd be left in the dust ...

Similarly to how they did with PostgreSQL and PostgREST ...

Besides, I also realised that winning the argument in the first place was basically impossible, because of that Silicon Valley is fundamentally corrupt, only allowing for retarded projects, funded by retarded VC funds, willing to bribe the retarded Silicon Valley presstitutes, to get attraction and have retarded articles written about their retarded platform. If I had my will, there would be warning signs on your IDE in its splash screen saying ...

"Littering your codebase with Supabase code will result in an $8,000 fine"

In addition, we'd implement virus killers automatically finding and weeding out Supbase code on development machines, the same way we have virus killers looking for Trojans and worms today on PCs.

Over the years you will see 10,000+ articles written about Supabase by "tech journalists", most of whom are probably paid for by Supabase themselves, with money taken from VC companies, resulting in getting a lot of attention for something 100% of every single experienced software developer knows for a fact is a platform built on top of mud - And I simply couldn't compete with that. The fact that Magic was a 1,000 times better idea than Supabase was irrelevant ...

... so I closed Magic!

Idiocy-based math

PostgREST has 3,742 commits at the time of this writing.

943 have been done by steve-chavez
688 have been done by begriffs
492 have been done by wolfgangwalther

This implies that 2,123 of commits to the codebase of PostgREST was created by 3 people. This is 57% of the entire codebase. This is not unique for PostgREST. Similar numbers can be found for huge projects such as nGinx, arguably powering 50% of the World Wide Web. The last time I calculated the same figures for nGinx, about 80% of its entire codebase was done by 2 devs. nGinx was sold for (I think) 600 million dollars some few years ago.

Facts are, most successful software projects have 1 to 3 devs actively maintaining and contributing to its codebase. To put this into perspective, realise the following truth ...

Supabase is not a company! It's 3 devs with a 50+ strong marketing team, and enough money to bribe half of Silicon Valley, to have 10,000+ articles written by the presstitutes, trying to convince junior devs about its brilliance - When there are in fact no brilliance!

I would know, having 15,000+ commits towards GitHub the last 5 years, without a marketing team, or corrupt VC companies bribing the presstitutes of Silicon Valley to get a good ROI. While we're at it, why on earth do companies have to pay for the media writing articles about news worthy stuff? When did that ever become "OK" ...?

Psst, if you're running to count my commits now, realise they're nullified when you change your email address, and I've change mine twice the last 5 years. However, I'm the by far most productive developer in Cyprus according to GitHub if you count all my commits. In Magic alone I've got more than 8,000 commits, putting me far above the guy who's apparently number 1 in the island of Cyprus. I've also got 50+ additional projects I've been maintaining over the last 5 years.

If you count commits as cognitive work, Magic had 8,007 at the time I closed its source code. This is almost 3 times as much as PostgREST. Later it's been accumulating some roughly 570 additional commits. 99% of these commits are done by yours truly.

This implies that if commits are a measure stick of mental energy applied to a code base (they usually are!) - Then Magic has almost 3 times as much mental work applied to it as Supabase's "core project" (PostgREST). And when I started Magic's codebase in 2019, I already had 37 years of software development experience (I started coding when I was 8) - So it's obviously not some "toy project" ...

So if you were to measure Magic's value according to Supabase math, it should be worth almost 3 times as much as Supabase, implying roughly 3 billion US dollars.

So where are my 3 billion dollars ...?

Silicon Valley, the Destroyer of Everything that's Beautiful in this world

The problem isn't the 3 devs originally having created PostgREST. They'll probably wake up one day realising what they've done, SHIFT+DELETE their codebase, and maybe contribute to the world with something that's actually beautiful. Most junior devs don't have any clue what so ever what they're doing, and with some motivation and learning over time, they typically end up understanding how to create great software after having wasted 20+ years of their lives having created rubbish code.

I would know having had my 15 minutes of shame ending up as a "great example of how to build a great GUI library" on Bjarne Stroustrup's personal home page. If you don't understand the irony of that statement, realise you can't build a great GUI library in C++ - In fact, you can't build anything that's great with C++.

I started SmartWin++ 25 years ago, so I was still young, and fell for marketing rubbish created by 50+ years of corrupt software development "journalism" in Silicon Valley, created by presstitutes in San Francisco, convincing us about OOP's superiority to procedural programming.

I swear to the mother of the Banana Tree that there's no way to explain OOP's popularity besides using words such as "false flag operation" or "intentionally dumbifying software developers" ...

Silicon Valley, and specifically the VC industry, is ipso facto destroying everything that's beautiful in this world. They're consistently allowing for bad ideas to prevail, because of their greed for some "fast bucks", capitalising on rubbish ideas, leaving others "holding the bag".

Most people would argue that VC is a pre-requisite for innovation. I would argue that VC is the primary enemy of innovation - Because it ensures 100% of the time that only bad ideas survives, while great ideas don't. Don't believe me? Realise that C# is still playing catch up with great ideas from Lisp. Lisp was created in the 1950s. Of course you'd probably see Microsoft publicly acknowleding North Korea's leader as "our supreme leader" before they'd publicly admit that fact - But at least internally they've done some great work to catch up with Lisp ...

Software development has been in a non-stop downwards spiral now for 70 years, AKA; Devolution!

When you're VC funded, creating great stuff becomes 100% irrelevant - And if you're interested in building great stuff in the first place, there's no way in hell that you'll ever get funded - Similarly to how the music industry has consistently been favouring garbage artists now for 50+ years, since the 1970s, when the last great music was created.

VC is not about building great stuff, it's a Ponzi scheme, artificially inflating popularity of some rubbish idea, to cash out some fast bucks - And in the process, millions of junior devs are hammering out garbage projects, built on garbage ideas, because of learning from YCombinator that "34% of all YC startups are built on Supabase."

In case you don't get the joke, that says nothing about Supabase, but it tells you everything you need to know about YC and the rubbish companies they're subsidising!

This perpetuates garbage, spreading it evenly out on to the world, similarly to how cancer will infect its host, consume all nutrients, leaving the host organism to die in a pool if sjait.

When this article went viral on Twitter, one person was hinting towards me being jealous. This article is my answer to him, and in case it's too long to read, let me emphasise its conclusion.

I've spent most of my professional life maintaining garbage code, because of its initial devs believing in garbage architecture, created by rubbish companies, to make some fast bucks, cashing in on other peoples' ignorance, without a care about how things should have been implemented in the first place - And I'm quite frankly tired of picking up your garbage! Do it yourselves! Magic is closed source! Period!

Don't like it? Pay me $5,000 per month for a single server license, or $20,000 per month for a K8S license!

Conclusion - The CAP theorem

While we're at it, let's look at Supabase's slogan; "Build in a weekend, scale to millions". The CAP theorem dictates that you can only have two of the following.

Consistency
Availability
Partition tolerance

Typically, the CAP theorem implies you have to chose between consistency and availability. Availability again is a technical term for "scalability." PostgREST's primary value proposition is being capable of taking an RDBMS such as PostgreSQL and wrapping it inside of an HTTP API. Your RDBMS is typically built with consistency at 100% due to ACID compliance, making availability suffer. This implies that there is no availability guarantee in PostgreSQL by the very definition of the laws of physics!

Ignoring the fact that Supabase adds 3 additional (unnecessary) network invocations on every request originating from the client, reducing scalability by a factor of 16, the laws of physics themselves proves the slogan is a lie - Because an RDBMS such as PostgreSQL simply cannot due to the laws of physics "scale infinitely" due to ACID compliance - At least not without applying such an amount of caching that you've now effectively disconnected your app completely from your RDBMS, resulting in that the entire PostgreSQL feature is no longer to be seen anywhere in your app.

But hey, what do I know? It's only science. Maybe Supabase have somehow found a wormhole or something, allowing them to actually scale beyond what the laws of physics dictates ... 🤪

When your Supabase app crashes and burns, I'll clean it up, I always do. In fact, cleaning up other people's garbage sometimes seems to have been my lot in life. However, this time it's different, because it'll take me 10 hours to wipe your ass, but I'll still charge you $5,000 per month, for the life cycle of your app - With one year minimum binding time, paying up front for 12 months initially - Assuming you want an on premises solution. If you don't understand why, let me enlighten you a bit here ...

YOU'RE PAYING FOR THE YEARS, NOT THE HOURS!!

And I'm tired of wiping your ass without getting paid ...

And for the next time, maybe hire somebody initially who knows what the fuck they're doing, instead of putting 500 teenagers into a room, paying them with pizza and coke, praying to get something functioning out of them after a year of smashing their keyboards like monkeys, expecting them to create Shakespeare ...

Now please explain to me how the fuck this garbage acquired 68,000 licks when it seems as if it's a pre-requisite having brain damage or being mentally disabled somehow to actually voluntarily wanting to use it ...?

Have a najs day 😊

Have a Custom AI Solution

At AINIRO we specialise in delivering custom AI solutions and AI chatbots. If you want to talk to us about how we can help you implement your next custom AI solution, you can reach out to us below.