DEV Community: Kamal Kant Prasad

Kafka vs Amazon SQS: Queue or Log? How to Pick the Right One on AWS

Kamal Kant Prasad — Thu, 29 Oct 2026 03:51:06 +0000

Sooner or later, every team building on AWS hits the same fork in the road: two services need to talk asynchronously, and you have to choose between Amazon SQS and Apache Kafka.

The usual framing is "SQS is simple, Kafka is powerful." That's true, but it hides the difference that actually matters:

SQS is a queue. A consumer takes a message, processes it, deletes it.
Kafka is a log. Messages stay for as long as you configure, and every consumer keeps its own bookmark.

Once you see it that way, the choice gets a lot easier.

SQS in 30 seconds

SQS is fully managed: no brokers, no partitions, no disks to size. Producers send, consumers poll, and a received message stays hidden for the visibility timeout. Delete it in time and it's gone for good; crash, and it reappears for another worker.

aws sqs send-message --queue-url $QUEUE_URL \
  --message-body '{"orderId": 4821, "total": 59.90}'

aws sqs receive-message --queue-url $QUEUE_URL \
  --max-number-of-messages 10 --wait-time-seconds 20

# delete only after the work really succeeded
aws sqs delete-message --queue-url $QUEUE_URL --receipt-handle $HANDLE

Standard queues: at-least-once delivery, best-effort ordering, practically unlimited throughput.
FIFO queues: strict ordering per message group plus 5-minute deduplication, at lower throughput.
Retention: 1 minute to 14 days, then SQS drops the message.

Kafka in 30 seconds

Kafka writes messages to topics split into partitions, which are append-only files. Reading doesn't delete anything; consumers just move an offset.

# billing and analytics read the same topic with independent offsets
kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic orders --group billing
kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic orders --group analytics --from-beginning

That last part is the superpower SQS doesn't have. Add a fraud-detection service six months from now and it can read every order still in retention, without the producer changing a line.

Quick comparison

	Amazon SQS	Apache Kafka
Model	Queue, deleted after processing	Log, retained with offsets
Operations	Fully run by AWS	You, or MSK / Confluent Cloud
Many consumers, same message	Needs SNS fan-out to several queues	Built in via consumer groups
Replay	No	Yes, reset offsets
Ordering	None (Standard) / per group (FIFO)	Per partition
Pricing	Per request, 1M free/month	Per broker or cluster hour + storage

Pick SQS when...

Each message is a job: resize an image, send an email, generate a PDF. Once it's done, nobody needs it again.
You want zero ops. Wire it to Lambda and AWS handles polling, batching and scaling. Failures go to a dead-letter queue with one redrive policy.
Traffic is low or spiky. An idle queue costs close to nothing (just turn on long polling so empty receives don't add up).

Pick Kafka when...

The same event matters to many systems: billing, inventory, search, the data warehouse. Each is just another consumer group.
You need replay. A buggy consumer wrote bad data for two days? Fix it and rewind only that group:

kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --group analytics --topic orders \
  --reset-offsets --to-datetime 2026-10-01T00:00:00.000 --execute

You're doing event sourcing, CDC with Debezium, or stream processing with Kafka Streams / Flink.

The cost nobody puts in the table

Self-hosted Kafka is real work: sizing brokers, picking partition counts up front, watching consumer lag, handling upgrades. Amazon MSK removes the servers, but you still pay for brokers running 24/7, and a small multi-AZ cluster lands in the hundreds of dollars a month before storage. For a three-person team shipping a SaaS app, that gap versus an idle SQS queue is significant.

If you want a replayable log but prefer to stay AWS-native, Kinesis Data Streams sits in the middle: multiple consumers, up to 365 days of retention, no brokers, but without Kafka's ecosystem.

The one-question rule

After a message is processed, does anything ever need to read it again?

No → start with SQS.
Yes, or several independent systems consume the same events → Kafka.

And plenty of teams run both: Kafka carries core business events between services, while SQS queues at the edges handle the jobs those events trigger.

📖 Want the full breakdown? The complete guide covers FIFO vs Standard queues, MSK pricing, Kinesis, and a detailed FAQ: Kafka vs Amazon SQS: Which Messaging Service Is Better? on Online ToolKit Hub.

Working with message payloads? Check out the free tools at onlinetoolkithub.com to format and validate JSON right in your browser.

Which one does your team use, and why? Let me know in the comments 👇

Resizing, compressing and converting a batch of images in the browser, without uploading them

Kamal Kant Prasad — Thu, 29 Oct 2026 03:21:15 +0000

I'm Kamal, the developer behind OnlineToolkitHub, a site with 250+ free browser tools. This post is about how one of its workflows, Resize, Compress & Convert Images, works under the hood.

Anyone who has built or run a website knows the routine. A client sends twenty photos straight off their phone. Each one is 4032×3024 pixels and 3–5 MB. Before they go anywhere near a page, every single file needs the same three jobs: shrink it, compress it, and convert it to something lighter than JPEG.

Most "compress image online" sites handle this by uploading your files to a server, processing them there and sending them back. That works, but it means handing your photos to a stranger's server, and phone photos carry more than pixels: the camera model, the time they were taken and often the exact GPS location.

None of this work needs a server. A browser can decode an image, resize it, and re-encode it as WebP on its own. So the workflow does everything inside the tab.

The shape of the tool

The UI is deliberately small and follows the three jobs in order:

Add images. Drop in as many JPG, PNG or WebP files as you like.
Resize and compress. Set one number (the longest side in pixels), pick a format (WebP, JPEG or PNG) and a quality value.
Download. Check the before/after sizes and download one file or all of them.

There's no sign-up, no watermark and no daily limit. One set of settings applies to the whole batch, because that's how people actually prepare images for a site: every photo in a blog post or product gallery wants the same treatment.

The defaults are a longest side of 1600 px, WebP and quality 80. That's a sensible starting point for most sites: big enough for a full-width image on a laptop, small enough not to hurt page speed.

One number for resizing: the longest side

Asking for "width and height" is a trap for batch work. A batch usually mixes landscape and portrait photos, and a fixed width would make the portrait shots enormous. So the tool asks for a single value, the longest side, and scales each image so that its longer edge fits:

// Simplified: fit the longest side, never upscale.
function targetSize(w, h, maxSide) {
  const scale = Math.min(1, maxSide / Math.max(w, h));
  return {
    width: Math.round(w * scale),
    height: Math.round(h * scale),
  };
}

The Math.min(1, …) matters. An image that's already smaller than the limit is left at its original size, because scaling a small image up only adds pixels the camera never captured. You can see this in the results further down: a 4032×3024 landscape becomes 1600×1200, a 3024×4032 portrait becomes 1200×1600, and a 1200×800 thumbnail stays 1200×800.

Re-encoding with a canvas

Once the target size is known, the image is drawn onto a canvas at that size and the canvas is exported in the chosen format. The core of it looks roughly like this:

// Simplified sketch of the per-file pipeline.
async function processImage(file, { maxSide, type, quality }) {
  const img = await loadImage(file);              // decode locally via an object URL
  const { width, height } = targetSize(img.naturalWidth, img.naturalHeight, maxSide);

  const canvas = document.createElement("canvas");
  canvas.width = width;
  canvas.height = height;

  const ctx = canvas.getContext("2d");
  ctx.imageSmoothingQuality = "high";
  ctx.drawImage(img, 0, 0, width, height);

  // type: "image/webp" | "image/jpeg" | "image/png"
  // quality: 0..1, ignored by the browser for PNG
  return new Promise((resolve) =>
    canvas.toBlob(resolve, type, quality / 100)
  );
}

canvas.toBlob() uses the browser's own encoders, so there's no image library to download. WebP support is built into every current browser, and WebP is typically 25–35% smaller than a JPEG at the same visual quality, which is why it's the default.

The result of each file is a Blob. The preview thumbnails and download buttons point at blob: URLs created from those blobs, which only exist inside your tab. When you clear the batch, the URLs are revoked with URL.revokeObjectURL() so the memory is released.

What the numbers looked like

For this post I ran a batch of four test JPEGs through the defaults (1600 px, WebP, quality 80):

File	Before	After
IMG_2041	4032×3024 · 1.70 MB	1600×1200 · 126.3 KB
IMG_2042	3024×4032 · 1.75 MB	1200×1600 · 134.4 KB
banner-hero	4000×2250 · 1.48 MB	1600×900 · 112.0 KB
thumb-small	1200×800 · 237.9 KB	1200×800 · 58.4 KB
Total	5.17 MB	431.1 KB (92% smaller)

Your numbers will depend on the photos. Real camera images with lots of fine detail compress less than flat graphics, but a 3–5 MB phone photo usually lands at a few hundred KB, with no difference you'd notice on screen. Most of the saving comes from the resize: going from 12 megapixels to about 2 cuts the pixel count by roughly 85% before compression even starts.

What doesn't survive

It's better to be upfront about what re-encoding through a canvas does and doesn't keep:

EXIF metadata is dropped. A canvas holds pixels, not metadata, so camera details, timestamps and GPS coordinates don't make it into the output. For the web that's usually exactly what you want, but keep your originals if you need that data. (If you only want to remove metadata without touching anything else, there's a separate Strip Image Metadata tool on the site.)
Animated GIFs become a single still frame. Drawing a GIF onto a canvas captures only its current frame.
Quality doesn't affect PNG. PNG is lossless, so the browser ignores the quality argument. PNGs only get smaller through resizing. If a PNG is still too big, export as WebP instead, which also keeps transparency.
The output is a fresh encode, not the original bytes. Unlike lossless operations, this is a lossy conversion by design. Don't run the same image through it repeatedly; always start from the original.

Memory is the real limit

There's no fixed cap on how many images you can add, but everything happens in your browser's memory. A decoded 12-megapixel photo takes around 48 MB as raw pixels while it's being drawn, regardless of how small the JPEG file was. Decoding a whole batch at the same time multiplies that peak, which is what can freeze or crash a tab on a phone.

In practice, a few dozen phone photos is fine on most laptops. For hundreds, work in smaller batches.

Checking that nothing gets uploaded

"Your photos aren't uploaded" is a promise, and you shouldn't have to take my word for it. You can check it yourself in about a minute:

Open the workflow page.
Open DevTools (F12 or Cmd+Option+I) and go to the Network tab.
Add a few images and click Process images.

When I did this while writing the post, the requests during processing were:

blob: GETs. These are the browser reading the files you picked and showing previews. They never leave the tab.
Analytics. The site uses Google Analytics and Microsoft Clarity for anonymous usage stats. The analytics event for this workflow records that a batch was completed and how many images were in it. It doesn't include file names or image data.

There's no request that sends your images anywhere, because there's no server endpoint for this workflow to send them to. You still need an internet connection to load the page itself.

Just need one step?

The workflow chains three jobs, but each one also exists as its own tool with a few extra options:

Resize Image: just the resize step.
Compress Image: just compression (75–85 is the usual sweet spot for photos).
JPG to WebP Converter: format conversion only, no resizing.

Wrapping up

The whole workflow is a single page, a resize calculation, one drawImage call and one toBlob call per file. It's free, there's no account, and your photos stay on your device.

Try it here: Resize, Compress & Convert Images

If you're working on something similar, I'd like to hear how you handle EXIF orientation on older browsers, or whether you've had better results with a WASM encoder like MozJPEG or libwebp than with the browser's built-in ones. That's the next thing I'd like to look at.

AWS Lambda vs ECS: Which One Should You Actually Use?

Kamal Kant Prasad — Sun, 13 Sep 2026 09:20:33 +0000

One of the AWS questions I keep coming back to when designing backend systems is:

Should this run on Lambda, or should I put it in a container on ECS?

At first glance, the two can look like competing choices. Both let you run applications without directly managing traditional servers, both can scale, and both fit nicely into modern AWS architectures.

But once you actually build with them, the differences become pretty clear.

Lambda is built around functions and events. ECS is built around containers and services.

And that difference matters more than the marketing terms around them.

Lambda feels very different from running a service

With AWS Lambda, you usually think in terms of a function responding to something:

HTTP Request
↓
API Gateway
↓
Lambda
↓
Response

Or:

S3 Upload
↓
Lambda
↓
Process File

Or:

SQS Message
↓
Lambda
↓
Process Message

You don't normally worry about keeping the application running.

AWS takes care of provisioning and scaling the execution environment.

This makes Lambda particularly attractive for event-driven and unpredictable workloads. AWS describes Lambda as an event-driven compute service where AWS manages the underlying compute resources.

And there is something really nice about that model.

If your application receives 10 requests and then nothing for an hour, you aren't maintaining an always-running application just waiting for traffic.

ECS is a different mental model

With ECS, you're thinking about a containerized application.

For example:

Internet
↓
Application Load Balancer
↓
ECS Service
↓
Docker Container
↓
Your Application

Your container keeps running as a service.

You can run ECS tasks using Fargate, where AWS manages the underlying infrastructure, or using EC2 capacity. ECS therefore gives you considerably more control over how your containerized application runs.

This is especially useful when your application isn't naturally a short-lived function.

Maybe you're running:

Django
FastAPI
Node.js
Spring Boot
a background worker
a WebSocket service
a custom Docker image

If you already have a Dockerized application, ECS can feel very natural.

The biggest difference: how your application runs

This is the part I would focus on first.

AWS Lambda  Amazon ECS

Basic model Function Container
Typical workload Event-driven Service-based
Runtime Up to 15 minutes per invocation Long-running
Scaling Managed automatically You configure service scaling
Scale to zero Yes Not typical for services
Runtime control More constrained Much more control
Containers Supported as packaging Native model
Best for Bursty/event-driven workloads Long-running services

AWS currently describes Lambda as a function deployment and ECS as a container orchestrator. AWS also recommends ECS for workloads that need to run longer than 15 minutes or need environments outside AWS Regions.

Where Lambda really shines

I particularly like Lambda when the workload is naturally event-driven.

Imagine you have a file processing system:

User uploads PDF
↓
S3
↓
Lambda
↓
Process PDF
↓
Save result

You don't need a server sitting there all day waiting for someone to upload a PDF.

Lambda wakes up when there's work.

The same pattern works nicely for:

scheduled jobs
queue processing
image processing
notifications
lightweight APIs
database events
S3 events
automation workflows

It's also useful when traffic is unpredictable.

You might have almost no requests at 3 AM and suddenly receive thousands during the day. Lambda is designed to handle that kind of changing demand without you having to manually provision capacity ahead of time.

But Lambda isn't always the answer

This is where I think developers sometimes get carried away with serverless.

Just because Lambda can run your code doesn't mean your entire backend should become a collection of Lambda functions.

Consider a Django application.

You may have:

Django
PostgreSQL
Redis
Celery
WebSocket
Background Workers

Trying to force every component into Lambda can introduce unnecessary complexity.

You may also have a process that needs to run for longer than Lambda's maximum invocation duration.

Or perhaps your application needs a custom runtime, native dependencies, persistent connections, or more control over the container environment.

That's where ECS starts becoming much more attractive.

AWS specifically points to ECS for long-running workloads, custom runtimes, and applications that need more control over their container environment.

What about cost?

This is probably the most misunderstood part of the Lambda vs ECS discussion.

People often ask:

Which one is cheaper?

The honest answer is:

It depends on your workload.

Lambda charges based on invocations and execution duration.

ECS pricing depends on how you run it. With Fargate, you pay for the requested compute resources while the tasks are running. With ECS on EC2, you're paying for the underlying EC2 capacity.

So imagine two applications.

Application A

It receives occasional requests:

10 requests
↓
Nothing
↓
50 requests
↓
Nothing
↓
20 requests

Lambda can be very attractive here because you aren't keeping an application running continuously just to handle occasional traffic.

Application B

It receives steady traffic all day:

████████████████████████
████████████████████████
████████████████████████

Now an always-running ECS service can become much more attractive.

AWS's own recent FinOps guidance makes the same point: workload characteristics, traffic patterns, operational requirements and actual cost modeling should drive the decision rather than assuming one compute model is always cheaper.

So don't choose based on a generic "Lambda is cheaper" or "containers are cheaper" statement.

Run the numbers for your workload.

You don't actually have to choose one

This is probably my favorite part of the whole discussion.

You can use Lambda and ECS together.

For example:

                Users
                  |
                  v
          Application / API
                  |
                  v
                ECS
                  |
      ┌───────────┴───────────┐
      |                       |
   Database                 Queue
                              |
                              v
                           Lambda
                              |
                              v
                        Background Job

Your main API might run continuously on ECS.

Then Lambda handles things that are naturally event-driven:

processing uploaded files
sending notifications
scheduled cleanup
queue processing
generating reports

AWS itself notes that many applications use both approaches in production because they solve different problems.

And honestly, this is often a much better architecture than trying to force everything into one compute model.

What would I choose?

I would start with the workload rather than the AWS service.

If I'm building something that is:

Event-driven + unpredictable + relatively short-lived

I'd look at Lambda first.

If I'm building:

A long-running application + custom Docker environment + steady traffic

I'd look at ECS.

If I'm building a larger application?

I'd probably consider both.

For example:

ECS
→ Main API

Lambda
→ Background processing

SQS
→ Decouple workloads

RDS
→ Relational data

S3
→ Files

CloudWatch
→ Monitoring

The architecture becomes more about using each service where it makes sense rather than trying to find one AWS service that does everything.

One practical rule I use

When I'm unsure between two infrastructure options, I ask:

What is the natural lifecycle of this workload?

If the answer is:

"It wakes up, does something, and finishes."

Lambda is probably worth considering.

If the answer is:

"This application needs to stay available and continuously serve requests."

ECS starts making more sense.

And if the answer is:

"Some parts do both."

Use both.

Final thoughts

Lambda and ECS aren't really direct replacements for each other.

They're different execution models.

Lambda gives you functions, events, automatic scaling and very little infrastructure to manage.

ECS gives you containers, long-running services and much more control over the application environment.

The right choice depends on traffic, runtime requirements, application architecture, cost, and how much control your team needs.

And don't forget that the decision isn't permanent. AWS architectures can evolve as workloads change.

If you're currently deciding between the two, I wrote a more detailed comparison covering runtime limits, cold starts, scaling, Docker support, cost, and practical use cases:

👉 Read the full guide:
https://www.onlinetoolkithub.com/blog/aws-lambda-vs-ecs

AWS #AWSSolutions #Lambda #AmazonECS #CloudComputing #Serverless #Docker #DevOps #SoftwareArchitecture #CloudArchitecture

OpenSearch vs Elasticsearch: What’s Actually Different?

Kamal Kant Prasad — Fri, 11 Sep 2026 06:59:13 +0000

If you've worked on backend systems for a while, chances are you've heard of Elasticsearch.

Maybe you've used it for application search.

Maybe you've seen it in a logging stack.

Or maybe you've inherited a production system where someone says:

“The logs are in Elasticsearch.”

Then, at some point, you hear another name:

OpenSearch

And the obvious question is:

“What's the difference? Aren't they basically the same thing?”

That's a fair question.

They actually do have a common history. OpenSearch started as a fork of Elasticsearch 7.10.2, so a lot of the concepts feel familiar. But the two projects have been evolving independently for several years now.

That means choosing between them today isn't simply a matter of picking a different name for the same technology.

The decision can affect your licensing, APIs, cloud architecture, dashboards, integrations, team experience, and even your future migration options.

So let's look at this the way I'd approach it when making an actual engineering decision.

First, what problem are we trying to solve?

Before comparing OpenSearch and Elasticsearch, it's worth asking why we'd use either of them in the first place.

Imagine you're building an e-commerce application.

You have millions of products.

A user searches:

wireless headphones

They don't just expect a database query that returns matching rows.

They expect:

relevant results
typo tolerance
filters
sorting
fast responses
maybe autocomplete
maybe ranking based on relevance

That's where a search engine becomes useful.
The same technology can also be used for things like:

application logs
observability
security analytics
monitoring
real-time analytics
large-scale text search

Both Elasticsearch and OpenSearch are designed for these kinds of workloads.

So we're not really comparing a good product with a bad product here.

We're comparing two technologies that started from a similar foundation but have taken different paths.

Elasticsearch: the technology most developers already know

Elasticsearch is a distributed search and analytics engine built on Apache Lucene.
You can send documents to Elasticsearch, index them, and then search those documents very quickly.
For example, a simplified flow might look like:

Application
|
v
Elasticsearch
|
v
Search index
|
v
Relevant results

But Elasticsearch isn't limited to application search.

It's commonly used for:

website search
product search
log analysis
observability
security analytics
monitoring
real-time analytics

It also comes with the wider Elastic ecosystem, including Kibana and other capabilities around observability, security, analytics and machine learning.

If you've worked with the Elastic Stack before, you probably already know how useful that ecosystem can be.

Then OpenSearch appeared

OpenSearch came out of an important change in the Elasticsearch ecosystem.

In 2021, Elastic changed the licensing of Elasticsearch and Kibana away from Apache 2.0.

AWS and other organizations created OpenSearch from Elasticsearch 7.10.2 and continued development under the Apache 2.0 license.

That's why OpenSearch can feel very familiar to someone who has used older Elasticsearch versions.

The concepts aren't strange.
You still have indexes.
You still have documents.
You still have queries.
You still have distributed clusters.
And you still have dashboards.
But the projects are no longer moving together.
That's the part developers need to remember.

The licensing difference matters more than it first appears

For an individual developer experimenting on a laptop, licensing might not be the first thing you think about.

For a company, it can become a major architectural consideration.

OpenSearch is released under the Apache License 2.0.

Elasticsearch has a more complicated licensing model today, with AGPLv3, SSPL and Elastic License 2.0 options for applicable source code, while Elastic's default distribution is under the Elastic License 2.0.

I'm not going to say one license is universally better.

That's not really the point.

The point is that your organization may already have rules around what licenses it can use.

So if you're starting a new system, licensing should be one of the questions you answer before choosing the technology—not after you've built half the platform around it.

What about API compatibility?

This is where the history between the two projects can be both helpful and confusing.

Because OpenSearch started from Elasticsearch 7.10.2, there is significant historical compatibility.

Some Elasticsearch 7.10-era APIs are compatible with OpenSearch.

That sounds great until someone interprets it as:

“So I can just replace Elasticsearch with OpenSearch.”

I wouldn't make that assumption.

The projects have been developing independently since the fork.

Modern Elasticsearch and modern OpenSearch have different APIs, features and ecosystems.

Even OpenSearch recommends using OpenSearch clients when working with OpenSearch rather than assuming Elasticsearch clients will always be compatible.

For a new project, I'd keep the architecture clean:

OpenSearch application
|
v
OpenSearch client
|
v
OpenSearch cluster

rather than deliberately depending on historical compatibility.
It makes the technology choice explicit and avoids surprises later.

If you're on AWS, the decision gets interesting

This is probably one of the first things I'd look at if I were designing an AWS-based application.

AWS provides Amazon OpenSearch Service, which supports OpenSearch and legacy open-source Elasticsearch versions.

It also integrates with other parts of the AWS ecosystem, including services such as IAM and CloudWatch.

So an AWS-heavy architecture might look something like:

                Application
                     |
                     v
          Amazon OpenSearch Service
                     |
                     v
                 OpenSearch
                     |
                     v
         Search / Logs / Analytics

That's convenient.

If your team is already comfortable with AWS and you're starting a new system, OpenSearch becomes a very natural option to evaluate.

But I wouldn't say:

“You're using AWS, therefore you must use OpenSearch.”

Architecture is rarely that simple.

If your company already has a large Elastic deployment, moving away from it just because you're running on AWS could create more problems than it solves.

What if your team already uses Elasticsearch?

This is where engineering decisions often become very different from technology comparisons.

Imagine your company has been running Elasticsearch for five years.

You already have:

production clusters
Kibana dashboards
alerting
monitoring
custom queries
applications using Elasticsearch clients
engineers who know the platform
operational processes around it

Someone then says:

“OpenSearch is open source. Let's migrate.”

Maybe.

But what problem are you actually solving?

Migration has a cost.

You need to think about indexes, mappings, queries, clients, plugins, dashboards, security settings, ingest pipelines, snapshots and application compatibility.

Sometimes the better engineering decision is simply:

Don't migrate unless you have a good reason.

Technology decisions aren't competitions.

If Elasticsearch is working well and your requirements haven't changed, staying with it can be the most sensible option.

OpenSearch Dashboards vs Kibana

Another thing people sometimes overlook is the UI layer.

OpenSearch has:
OpenSearch Dashboards

Elasticsearch has:
Kibana
Both can be used for:

dashboards
charts
log analysis
monitoring
search analytics
application metrics
security analytics

So at a high level, they solve a similar problem.

But if you migrate from one ecosystem to the other, don't assume you can simply export everything and import it without changes.

Dashboards and visualizations can become part of your infrastructure.

Over time, teams build a lot of operational knowledge around them.

That knowledge has value.

Which one is faster?

This is probably the question that creates the most misleading comparisons.

You'll find people saying:

“OpenSearch is faster.”

Others will say:

“Elasticsearch is faster.”

I'd be very careful with both statements.

Search performance depends on much more than the product name.

For example:

How large is your dataset?
How are your indexes designed?
How many shards do you have?
How many replicas?
What queries are you running?
How much memory is available?
What storage are you using?
What's your refresh interval?
How much caching is involved?
How many nodes are in the cluster?

You can have a badly designed Elasticsearch cluster and a well-designed OpenSearch cluster and reach the opposite conclusion.

For example:

Poor index design
↓
Slow query
↓
Add more servers
↓
Higher cost
↓
Still slow

Adding infrastructure doesn't magically fix a bad search design.

So if performance is an important part of your decision, benchmark your own workload.

Use your own data.

Use your own queries.

Measure latency, indexing speed, memory usage and infrastructure cost.

That's much more useful than trusting a generic benchmark.

The features are no longer identical

This is another reason old Elasticsearch vs OpenSearch comparisons can become misleading.

When OpenSearch first appeared, comparing the two was relatively straightforward because they shared a recent codebase.

That's not the situation anymore.

Both projects have had years to develop independently.

OpenSearch has added capabilities across areas such as machine learning, semantic search, indexing and data sources.

Elastic has also continued developing its own capabilities around search, observability, security, machine learning and AI.

So instead of asking:

“Which product has more features?”

I'd ask:

“Which features do I actually need?”

That's a much better engineering question.

Make a list.

For example:

My requirements:

✓ Full-text search
✓ Log analytics
✓ Dashboarding
✓ Vector search
✓ AWS integration
✓ Python client
✓ Security
✓ Good operational tooling

Then compare the products against that list.

Don't choose a platform because it has ten features your application will never use.

So which one would I choose?

Honestly, it depends.

If I'm starting a new application on AWS, I'd put OpenSearch high on the list.

The AWS integration and Apache 2.0 licensing make it worth evaluating, especially if the application needs search, analytics or log management.

If I'm joining a company that already has a mature Elastic Stack, I'd probably stay with Elasticsearch unless there is a strong reason to change.

The existing knowledge, dashboards, integrations and operational experience are worth something.

And if the requirements are unclear?

I'd benchmark both.

That's usually better than arguing about them in a meeting.

A simple decision framework

When I'm evaluating infrastructure technology, I like to reduce the decision to a few practical questions.

Are you starting a new AWS-heavy project?

OpenSearch is worth considering first.

Is Apache 2.0 licensing important?

OpenSearch deserves serious consideration.

Do you already have a large Elastic deployment?

Elasticsearch may still be the better choice.

Does your application depend on Elastic-specific features?

Stay with Elasticsearch unless there's a strong reason to migrate.

Are you unsure about performance?

Benchmark both.

Are you migrating an old Elasticsearch deployment?

Don't assume compatibility.

Check your:

Elasticsearch version
client libraries
plugins
mappings
queries
dashboards
security configuration

before making the decision.

One thing I wouldn't do

I wouldn't choose OpenSearch simply because:

“It's open source.”

And I wouldn't choose Elasticsearch simply because:

“Everyone knows Elasticsearch.”

Both are weak reasons.

A production technology decision should consider:

Requirements
↓
Licensing
↓
Features
↓
Cloud ecosystem
↓
Client compatibility
↓
Operational complexity
↓
Cost
↓
Team expertise

That's a much healthier way to make the decision.

Final thoughts

OpenSearch and Elasticsearch started from the same place, but they're not the same project anymore.

That's probably the most important thing to understand.

If you're building something new, don't treat OpenSearch as simply “old Elasticsearch with a different name.” And don't treat Elasticsearch as an outdated alternative either.

They are now two independently evolving ecosystems.

For an AWS-centric application, OpenSearch can be a very attractive option.

For a team already deeply invested in Elastic, Elasticsearch may continue to be the obvious choice.

And if you're sitting somewhere in the middle, don't overthink the brand names.

Write down what your application actually needs.

Run a realistic benchmark if performance matters.

Check the licensing.

Look at the clients and integrations you'll need.

Then choose.

Because the best search engine isn't the one that wins an internet comparison.