DEV Community: Mustafa Balila

Serverless Framework v4 Went Paid, Here Are the Real Alternatives

Mustafa Balila — Sat, 25 Apr 2026 08:21:29 +0000

Originally published on protomindlabs.com.

Serverless Framework v4 went paid in early 2024, and the serverless corner of my timeline has been arguing about it on and off ever since. Most of the noise misses the actual decision.

Here's the thing people skim past. The $2M annual revenue threshold means most indie builders and small startups pay nothing. Side project? Pre-Series A? You pay zero. The pricing page looks scary, but the bill is usually $0.

So the real question isn't "what's cheaper than v4." It's whether you want the config that defines your production infrastructure tied to someone else's revenue model. The $2M threshold today is a choice, and choices get revised. I've been burned by that exact pattern before, with a different tool but the same story, and it shapes how I pick infrastructure now.

Here's what actually changed, and what I'd reach for instead, depending on what you care about.

What v4 actually charges for

The v4 pricing model is narrower than the panic suggests. From the announcement post:

Organizations under $2M in annual revenue: free
Independent developers, open-source projects, consultants deploying for clients: free
Users staying on v3 or older: free, forever
Everyone else: starts at $49/month, billed per "Instance." This is defined as a unique combination of AWS account, stage, and region running a deployed service for more than 5 days in a calendar month

The 5-day rule is a real carve-out. Preview environments and ephemeral CI stacks don't count. It's the long-lived production stacks that rack up the bill.

And honestly, it's a reasonable business model. The Serverless Framework team has to pay engineers, and "enterprises pay, hobbyists free" is about as fair as that trade gets. My issue isn't the pricing itself. It's that once a tool starts taking money, its incentives shift toward what paying customers ask for, and away from the long tail. That's not a flaw, just how commercial software works. It does mean the math for starting a new project in 2026 is different from 2022.

The four real alternatives

These are the tools I'd actually consider if I were starting fresh today. Not a list of twelve options. Just the ones that solve a real variant of the problem.

1. AWS SAM, if you want AWS's own answer

SAM is a CloudFormation extension with a CLI. It's free, first-party, and about as safe a bet as it gets in terms of longevity. AWS ships it. The YAML is verbose, and you will probably curse it the first time you write a nested intrinsic function. The local dev loop with sam sync is decent, and the ecosystem is smaller than Serverless Framework's. Still, "smaller than SF" is larger than what most people actually need.

Pick SAM when you're deep in AWS, comfortable with CloudFormation's declarative model, and want to minimize external dependencies.

2. AWS CDK, if you want code instead of config

CDK lets you define infrastructure in TypeScript, Python, Java, or C#. It compiles down to CloudFormation. For anyone who has tried to write conditional logic in YAML, CDK is a relief.

The trade-off is the abstraction ceiling. L2 and L3 constructs hide complexity well, until they hide the one thing you need. Then you're back at L1, effectively writing CloudFormation in TypeScript. CDK works best for teams willing to build and maintain their own construct library. It is less forgiving if you expect to avoid CloudFormation entirely.

Pick CDK when you want a code-first approach, plan to standardize constructs across a team, and are committed to AWS.

3. SST, with one caveat

SST launched in 2020 to fix many of Serverless Framework's pain points. The sst dev live development loop is still one of the best in the category. It streams Lambda invocations to your laptop with hot reload. If you've ever been stuck in a deploy-debug loop, you know why that matters.

The caveat is that SST has been in maintenance mode since mid-2025. The team pivoted to OpenCode, an AI coding agent that scaled quickly. SST v3 still works and still gets maintenance updates, but active feature development has slowed.

"Maintenance mode" doesn't mean unusable. The framework is stable, and the docs are solid. But if your plan depends on future features, that roadmap is no longer the same.

Pick SST when you want a strong local development experience and are fine with a stable, low-change tool.

4. Terraform, if you want long-term stability

This is the one I picked for the SaaS kit. Terraform isn't a serverless framework. It's a general-purpose infrastructure-as-code tool with serverless support. It's more verbose than Serverless Framework, and you lose some convenience. The AWS provider can also feel awkward around Lambda packaging.

Still, it has been stable for years, supports multiple clouds, and the contract between you and the tool doesn't depend on your revenue. When you're selling something that people will run for years, the infrastructure layer should be predictable. Terraform fits that role.

HashiCorp's license change in 2023 raised concerns, and OpenTofu emerged as a fork. That fork is actively maintained and provides a viable open-source fallback. Having two viable paths reduces risk.

The fifth option: don't migrate

If you have a working v3 project and the $2M clause doesn't apply, the best option might be to do nothing. It is not exciting, but it is practical.

You can also switch to oss-serverless, a community fork maintained by the Bref team. It acts as a drop-in replacement for v3. Install it and keep going. The fork keeps Node.js runtimes up to date and patches dependencies. It does not aim to add new features, only to keep things stable.

Staying on a working tool, with a community-supported fork, and delaying migration until necessary is a reasonable approach.

Where v4 still wins

Serverless Framework v4 still has a place. If your team relies on its plugin ecosystem, the migration cost is significant. The plugin library represents years of accumulated work that alternatives do not fully match. For organizations above $2M in revenue, $49 per month is negligible.

The v4 pricing model does not make Serverless Framework a bad tool. It changes the nature of the commitment. If you would have chosen it in 2023, you would likely still choose it now.

What changed is that new projects have a stronger reason to evaluate alternatives. Those alternatives have matured enough to be viable.

If you're starting fresh in 2026, choose the tool whose pricing model you will not need to revisit later.

Database indexing and selectivity

Mustafa Balila — Fri, 17 May 2024 20:15:31 +0000

As you may already know, indexing is a great way to improve the performance of your queries. But is that really it?

There are no silver bullets, only trade-offs. What's the catch? There's always a catch!

When you create an index, the RDBMS creates a copy of your table containing one or more columns depending on how many columns you have indexed.

This copy will always be sorted, and it has to be maintained while inserting, updating, and deleting rows. That's why indexes slow down writes and lock tables during index creation.

Enough about the RDBMS job, let's talk about yours. Which columns should you index?
It depends!. Your queries should drive your indexes, but you can use column selectivity to decide if a column will make a good index or not.

Selectivity describes the uniqueness of values in a column.

A highly selective index is good because it filters out more rows in a search.

Let's imagine a table with columns for email, country, and gender.

The gender column is the least selective, since it can only - hold two values.
The country column is more selective since it can hold more values. The email column is the most selective because it's unique.

Selectivity affects search performance because it divides the table into slices and uses these slices for searching. Selective columns form smaller slices, which makes searching them faster.

How to find the selectivity of a column?
simply run this query:

select count(distinct column)/count(*) from table;

In postgres, you'll need to cast values to numeric for this to work

How do SQL interprets nulls?

Mustafa Balila — Mon, 13 May 2024 04:56:20 +0000

Null values in SQL, how are they different from traditional nulls?

null, nil, or none is a special value that most programming languages reserve, and it usually means nothing or no value.

Developers usually mistake SQL nulls for having the same meaning, and they end up writing queries that produce unexpected results or a behaviour that is hard to debug.

SQL interprets null as I don’t know or unknown value rather than nothing or no value.

What does that mean?

To understand SQL nulls, we first need to know about the three valued logic. Assume that you are a database engine (cool right?), and you're given two black boxes (A) and (B) and asked to compare their content:

Is black box A the same as black box B? You don't know.
Okay, is A greater than B? You still can't tell!
How about A being less than B? No idea!
Hmm, maybe A = B is doable? Nope.

And that's exactly how a database engine treats null values; it just doesn't know.

How do we compare values against null then?
It depends, Postgres for example, uses the is operator.
So A is B will evaluate true, and there are other functions that can handle null comparisons, like distinct.
And that's why you hear people advising against using nulls especially in columns with indexes, because they can affect your index efficiency (more on that on another article).
Next time when you use null, be mindful of this.

Below a picture of the null truth table to make it easier to understand.

How we reduced costs by switching from AWS MediaConvert to a Golang service

Mustafa Balila — Sat, 22 Jan 2022 19:40:10 +0000

This article will focus mainly on the golang side of work, so if you're interested please continue reading

The problem:
I'm working at a real state company. We allow our users to upload videos showing their proprieties and we used AWS MediaConvert to handle compressing and transcoding but things got out of hand. With MediaConvert a single minute of video encoding costs $0.03 for each video quality at 720p and above and $0.015 for each video quality below 720p. That way, if you encode at 720p, 480p, and 360p you pay – $0.06 per minute which is $3.6 per hour.

A screenshot from AWS MediaConvert pricing page

When you don't have many videos and the videos themselves aren't really long this is fine, but it'll start to cost more when your user base grows.

The solution:
I used golang and ffmpeg to create a service that allow us to replace MediaConvert. Go allows you to write concurrent code and it's really fast compared to other high programming languages like Python, Java, etc. With this in hand you can build really powerful things.
I've used go-fluent-ffmpeg for ffmpeg integration with go - I'm planning to switch to cgo bindings for more performance!. I've got this idea from a former college of mine, a really talented engineer phr3nzy

Here's the flow for how things were done

S3 is AWS simple storage service.
Lambda is a serverless, event-driven compute service.
SQS is a managed message queuing service.

Here's how the lambda code looks like



const aws = require("aws-sdk");
const sqs = new aws.SQS({ apiVersion: "2012-11-05" });
const s3 = new aws.S3({ apiVersion: "2006-03-01" });

exports.handler = async (event, context) => {
  const bucket = event.Records[0].s3.bucket.name;
  const key = decodeURIComponent(
    event.Records[0].s3.object.key.replace(/\+/g, " ")
  );

  try {
    const { ContentType, ContentLength } = await s3
      .headObject({ Bucket: bucket, Key: key })
      .promise();

    const [type] = ContentType.split("/"); // ["image", "jpeg"], ["video", "mp4"], ...

    if (type === "video") {
      // convert ContentLength from bytes to megabytes
      const size = ContentLength / (1024 * 2024);
      const messageBody = {
        originBucketName: bucket,
        originalFilePath: key,
        destinationBucketName: "",
        destinationBucketFolder: "",
        orientation: "landscape", // "landscape" || "portrait"
        resolution: "480", // 360 || 480 || 720
        size,
      };

      await sqs
        .sendMessage({
          MessageBody: JSON.stringify(messageBody),

          QueueUrl: process.ENV.VIDEO_QUEUE_URL,
        })
        .promise();
    }
  } catch (err) {
    console.log(err);
    throw new Error(err);
  }
};

After capturing the video data we send it to SQS then the go service should poll and process the video. I used Go AWS SDK to interact with AWS. and for the actual processing I've implemented a pipeline with three stages to process the videos.

Stage 1 - Downloading



func download(s3 *s3.Client, messages ...config.Message) <-chan config.DownloadedFile {
    out := make(chan config.DownloadedFile)
    go func() {
        defer close(out)
        for _, msg := range messages {
            fullpath, err := storage.DownloadObject(s3, msg.OriginBucketName, msg.Filename)
            if err != nil {
                log.Error(err.Error())
                return
            }
            name := strings.Split(msg.Filename, ".")
            format := strings.ToLower(name[len(name)-1])
            path := config.DownloadedFile{Fullpath: fullpath,
                Filename:                msg.Filename,
                DestinationBucketName:   msg.DestinationBucketName,
                DestinationBucketFolder: msg.DestinationBucketFolder,
                Resolution:              msg.Resolution,
                Orientation:             msg.Orientation,
                Format:                  format,
            }
            out <- path
        }
    }()
    return out
}

Stage 2 - Transcoding



func transcode(paths <-chan config.DownloadedFile) <-chan config.TranscodedFile {
    out := make(chan config.TranscodedFile)
    go func() {
        defer close(out)
        for file := range paths {
            unique := fmt.Sprintf("%s_%s_%s", file.Orientation, file.Resolution, file.Filename)
            outputPath := fmt.Sprintf("%s/%s", config.RootVideosDir, unique)
            ffmpeg := fluentffmpeg.NewCommand("")
            vError := ffmpeg.
                InputPath(file.Fullpath).
                FromFormat(file.Format).
                VideoBitRate(4 * 1042).
                FrameRate(30).
                AspectRatio(AspectRatios[file.Orientation]).
                Resolution(VideoResolutions[file.Resolution]).
                VideoCodec("libx265").
                ConstantRateFactor(VideoQualities[file.Resolution]).
                Preset("ultrafast").
                OutputFormat(file.Format).
                OutputPath(outputPath).
                Overwrite(true).
                Run()

            if vError != nil {
                log.Error(vError.Error())
                return
            }
            transcoded := config.TranscodedFile{
                DestinationBucketName:   file.DestinationBucketName,
                DestinationBucketFolder: file.DestinationBucketFolder,
                Fullpath:                file.Fullpath,
                LocalDiskPath:           outputPath,
                Orientation:             file.Orientation,
                Filename:                file.Filename}
            out <- transcoded
        }
    }()

    return out
}

Stage 3 - uploading



func upload(s3 *s3.Client, videos <-chan config.TranscodedFile) {
    go func() {
        defer close(errc)
        for video := range videos {
            dest := fmt.Sprintf("%s/%s",video.DestinationBucketFolder, video.Filename)
            storage.UploadVideo(s3, video.Fullpath, video.DestinationBucketName, dest)
            deleteFiles(video.Fullpath, video.LocalDiskPath)
        }
    }()
}

Finally I'd run the pipeline with this line



upload(s3Client,transcode(download(s3Client, messages...)))

Of course may need to add more but this is a showcase.

The code above uses goroutines which is how you write concurrent code in go.

Thanks for sticking to the end of the article!. Hope it helps.